[Intel-gfx] [PATCH CI run 3/3] drm/i915: Adding the parsing logic for the i2c element

New sequence element for i2c is been added in the mipi sequence block of the VBT. This patch parses and executes the i2c sequence. v2: Add i2c_put_adapter call(Jani), rebase v3: corrected the retry loop(Jani), rebase v4 by Jani: - don't put the adapter if get fails - print an error message

[Intel-gfx] [PATCH CI run 0/3] MIPI/DSI display support for APL

Test MIPI/DSI display suspend/resume cycle on Apollolake. Jani Nikula (1): drm/i915/bxt: add bxt dsi gpio element support Mika Kahola (2): drm/i915: Get the i2c bus number from the ACPI drm/i915: Adding the parsing logic for the i2c element drivers/gpu/drm/i915/i915_drv.c|

[Intel-gfx] [PATCH CI run 2/3] drm/i915: Get the i2c bus number from the ACPI

Currently for executing the i2c MIPI sequence, we are relaying on the i2c bus bunmber which is specified in the VBT. But there are cases where different Fab versions of the board will drive the same chip with different i2c port, in which case the i2c bus number from the VBT cant be relied on. To

[Intel-gfx] [PATCH CI run 1/3] drm/i915/bxt: add bxt dsi gpio element support

From: Jani Nikula Use a table similar to vlv to check for accepted gpio indexes. For now, add all, but this list should be trimmed down. Use managed gpio request, which will be automatically released when the driver is detached. Cc: Mika Kahola

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure. v4: * Remove the redundant variable link_train_failed v3: *

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: add i915_address_space_fini

== Series Details == Series: series starting with [CI,1/2] drm/i915: add i915_address_space_fini URL : https://patchwork.freedesktop.org/series/15520/ State : success == Summary == Series 15520v1 Series without cover letter

[Intel-gfx] [PATCH 0/5] Link Training failure handling during modeset

Submitting this series again since it had to be rebased dur to changes in drm that got merged. The idea presented in these patches is to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the

[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

CRTC state connector_changed needs to be set to true if connector link status property has changed. This will tell the driver to do a complete modeset due to change in connector property. Acked-by: Harry Wentland Acked-by: Tony Cheng Cc:

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

In the usual working scenarios, this property is "Good". If something fails during modeset, the DRM driver can set the link status to "Bad", prune the mode list based on the link rate/lane count fallback values and send hotplug uevent so that userspace that is aware of this property can take an

[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure. v3: * Remove fallback_link_rate_index variable, just obtain

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

On Thu, Nov 17, 2016 at 06:03:48PM -0800, Dhinakaran Pandiyan wrote: > static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr, > struct drm_dp_vcpi *vcpi, int pbn) > { > - int num_slots; > + int req_slots; > int ret; > > - num_slots =

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

On Thu, Nov 17, 2016 at 06:03:48PM -0800, Dhinakaran Pandiyan wrote: > The avail_slots member in struct drm_dp_mst_topology_mgr does not really > track the available time slots in a MTP(Multi-Stream Transport Packet). It > is assigned an initial value when the topology manager is setup but not >

[Intel-gfx] GTT memory allocation on E3800

Hi! First of all, I want to apologize for possible offtopic, I don't work with the Linux drivers, but I'm trying to figure out some details of e3800 graphics initialization process, and guys on Intel Embedded Community forum told me that maybe someone on this mail list could help me. I cannot

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

Hi Dhinakaran, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.9-rc5 next-20161117] [cannot apply to drm-intel/for-linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

[Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

The total or the nominal link bandwidth, which we save in terms of PBN, is a factor of link rate and lane count. But, currently we hardcode it to 2560 PBN. This results in incorrect computation of total slots. E.g, 2 lane HBR2 configuration and 4k@60Hz, 24bpp mode nominal link bw = 1080 MBps =

[Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

The avail_slots member in struct drm_dp_mst_topology_mgr does not really track the available time slots in a MTP(Multi-Stream Transport Packet). It is assigned an initial value when the topology manager is setup but not updated after that. So, let's use avail_slots to store the number of

[Intel-gfx] [PATCH 0/3] Track available link bandwidth for DP MST

The number of available time slots in a MTP should be updated when a new vcpi is added or an existing one is removed. Keeping this updated will be useful to reject modes for which there is not enough link bandwidth early. Dhinakaran Pandiyan (3): drm/i915/dp: Fail DP MST config when there are

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Fail DP MST config when there are not enough vcpi slots

drm_dp_find_vcpi_slots() returns an error when there is not enough available bandwidth on a link to support a mode. This error should make compute_config() to fail. Not returning false could end up in a modeset which will not work. Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH ddx 1/2] intel: Simplify new platform names.

Modern Intel (R) platforms with integrated graphics comes with common names varying the range numbers. So instead of listing all supported platforms let's start using the generic marketing strings without the numbers. And for the specific board we list it's actual marketing name if available on

[Intel-gfx] [PATCH ddx 2/2] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

This commit adding all known marketing names for latest gen9 platforms. v2: On top of simplified generic string names. Cc: Chris Wilson Signed-off-by: Rodrigo Vivi --- src/intel_module.c | 27 +++ 1 file changed, 27

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Cleaning up intel_dp_hpd_pulse

On Mon, Feb 01, 2016 at 11:13:08AM +0200, Ander Conselvan De Oliveira wrote: > On Mon, 2016-02-01 at 11:50 +0530, Thulasimani, Sivakumar wrote: > > > > On 1/29/2016 5:33 PM, Ander Conselvan De Oliveira wrote: > > > On Fri, 2016-01-29 at 14:31 +0530, Shubhangi Shrivastava wrote: > > > > On Tuesday

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

On Thu, Nov 17, 2016 at 09:03:42PM +, Vivi, Rodrigo wrote: > On Thu, 2016-11-17 at 19:35 +, Chris Wilson wrote: > > On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote: > > > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote: > > > > On Tue, Nov 15, 2016 at

[Intel-gfx] [CI 1/2] drm/i915: add i915_address_space_fini

From: Matthew Auld We already have an i915_address_space_init, so for symmetry we should also have a _fini, plus we already open code it twice. This then also fixes a bug where we leak the timeline for the ggtt vm. v2: don't forget about the struct_mutex for the ggtt

[Intel-gfx] [CI 2/2] drm/i915: don't leak global_timeline

From: Matthew Auld We need to clean up the global_timeline in i915_gem_load_cleanup. v2: don't forget about the struct_mutex, and also WARN_ON if we have any remaining timelines before purging the global_timeline. v3: it might be a good idea to first remove the

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

On Thu, 2016-11-17 at 19:35 +, Chris Wilson wrote: > On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote: > > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote: > > > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote: > > > > This commit adding all known

Re: [Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

On Thu, Nov 17, 2016 at 08:38:07PM +, Matthew Auld wrote: > We need to clean up the global_timeline in i915_gem_load_cleanup. > > v2: don't forget about the struct_mutex, and also WARN_ON if we have any > remaining timelines before purging the global_timeline. > > v3: it might be a good idea

Re: [Intel-gfx] [PATCH] drm/i915: add i915_address_space_fini

On Thu, Nov 17, 2016 at 08:53:15PM +, Matthew Auld wrote: > We already have an i915_address_space_init, so for symmetry we should > also have a _fini, plus we already open code it twice. This then also > fixes a bug where we leak the timeline for the ggtt vm. > > v2: don't forget about the

[Intel-gfx] [PATCH] drm/i915: add i915_address_space_fini

We already have an i915_address_space_init, so for symmetry we should also have a _fini, plus we already open code it twice. This then also fixes a bug where we leak the timeline for the ggtt vm. v2: don't forget about the struct_mutex for the ggtt path. Fixes: 80b204bce8f2 ("drm/i915: Enable

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: don't leak global_timeline (rev2)

== Series Details == Series: drm/i915: don't leak global_timeline (rev2) URL : https://patchwork.freedesktop.org/series/15439/ State : warning == Summary == Series 15439v2 drm/i915: don't leak global_timeline https://patchwork.freedesktop.org/api/1.0/series/15439/revisions/2/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

We need to clean up the global_timeline in i915_gem_load_cleanup. v2: don't forget about the struct_mutex, and also WARN_ON if we have any remaining timelines before purging the global_timeline. v3: it might be a good idea to first remove the global_timeline...duh! Fixes: 73cb97010d4f

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

On Thu, Nov 17, 2016 at 06:29:45PM -0200, Paulo Zanoni wrote: > Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > Let's try not to abuse plane->plane for sprites on VLV/CHV and > > instead > > use

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Let's try not to abuse plane->plane for sprites on VLV/CHV and > instead > use plane->id. Since out watermark structures aren't entirely plane > type > agnostic

Re: [Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

On Thu, Nov 17, 2016 at 08:20:05PM +, Matthew Auld wrote: > We need to clean up the global_timeline in i915_gem_load_cleanup. > > v2: don't forget about the struct_mutex, and also WARN_ON if we have any > remaining timelines before purging the global_timeline. > > Fixes: 73cb97010d4f

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] HAX drm/i915: Enable guc submission

== Series Details == Series: series starting with [1/3] HAX drm/i915: Enable guc submission URL : https://patchwork.freedesktop.org/series/15516/ State : failure == Summary == Series 15516v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15516/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

We need to clean up the global_timeline in i915_gem_load_cleanup. v2: don't forget about the struct_mutex, and also WARN_ON if we have any remaining timelines before purging the global_timeline. Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct") Cc: Chris

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

On Thu, Nov 17, 2016 at 06:07:36PM -0200, Paulo Zanoni wrote: > Em Ter, 2016-11-08 às 19:09 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > Use intel_plane->id to derive the VLV/CHV sprite register offsets > > instead of abusing

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Let's try not to abuse plane->plane for sprites on VLV/CHV and > instead > use plane->id. Since out watermark structures aren't entirely plane > type > agnostic

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

Em Ter, 2016-11-08 às 19:09 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Use intel_plane->id to derive the VLV/CHV sprite register offsets > instead of abusing plane->plane which is really meant to for > primary planes only. I think

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code

On Thu, Nov 17, 2016 at 05:12:13PM -0200, Paulo Zanoni wrote: > Em Qua, 2016-11-09 às 17:03 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > Nuke skl_wm_plane_id() and just use the new intel_plane->id. > > > > v2: Convert

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

On Thu, Nov 17, 2016 at 02:49:02PM +0200, Jani Nikula wrote: > On Tue, 15 Nov 2016, Manasi Navare wrote: > > If link training at a link rate optimal for a particular > > mode fails during modeset's atomic commit phase, then we > > let the modeset complete and then

Re: [Intel-gfx] [PATCH 0/5] Handle link training failure during modeset

On Thu, Nov 17, 2016 at 02:29:30PM +0200, Jani Nikula wrote: > On Tue, 15 Nov 2016, Manasi Navare wrote: > > Submitting new series that adds proper commit messages/cover letter > > and kernel documentation. It also moved the set_link_status function > > to drm core so

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only poll DW3_A when init DDI PHY for ports B and C. (rev2)

== Series Details == Series: drm/i915: Only poll DW3_A when init DDI PHY for ports B and C. (rev2) URL : https://patchwork.freedesktop.org/series/15139/ State : success == Summary == Series 15139v2 drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

On Thu, Nov 17, 2016 at 05:09:38PM -0200, Paulo Zanoni wrote: > Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > As I told people in [1] we really should not be confusing enum plane > > as a per-pipe plane

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

On Thu, Nov 17, 2016 at 02:58:46PM +0200, Jani Nikula wrote: > On Tue, 15 Nov 2016, Manasi Navare wrote: > > If link training fails, then we need to fallback to lower > > link rate first and if link training fails at RBR, then > > fallback to lower lane count. > > This

[Intel-gfx] [PATCH 1/3] HAX drm/i915: Enable guc submission

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index d46ffe7086bc..599b913d8906 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Split hw submission for replay after GPU reset

Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests.

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote: > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote: > > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote: > > > This commit adding all known marketing names for latest gen9 platforms. > > > > > > Cc: Chris

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use enum plane_id in SKL plane code

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane > code with intel_plane->id. > > This should make the SKL "primary" and "sprite" code

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add crtc->plane_ids_mask

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Add a mask of which planes are available for each pipe. This doesn't > quite work for old platforms with dynamic plane<->pipe assignment, > but > as we don't

[Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

According to Bspec we need to "Poll for PORT_REF_DW3_A grc_done == 1b" only on ports B and C initialization sequence when copying rcomp from port A. So let's follow the spec and only poll for that case and not on every port A initialization. v2: Also remove the grc_done check from

[Intel-gfx] [drm-intel:drm-intel-next-queued 2/2] drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: error: unused variable 'ggtt'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d commit: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d [2/2] drm/i915: Remove stolen object spam config: x86_64-randconfig-in0-11180217 (attached as .config) compiler: gcc-4.6 (Debian

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > As I told people in [1] we really should not be confusing enum plane > as a per-pipe plane identifier. Looks like that happened nonetheless, > so > let's fix it up

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code

Em Qua, 2016-11-09 às 17:03 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Nuke skl_wm_plane_id() and just use the new intel_plane->id. > > v2: Convert skl_write_plane_wm() as well > v3: Convert skl_pipe_wm_get_hw_state() correctly In

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote: > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote: > > This commit adding all known marketing names for latest gen9 platforms. > > > > Cc: Chris Wilson > > Signed-off-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 0/3] drm/i915/opregion: proper handling of DIDL, and some hacks on CADL

Hello, I can confirm that patch 3 is not needed. I applied only patch 1 and 2 and everything works super fine! Thanks again! BR Paolo -- Paolo Stivanin paolostiva...@fastmail.fm Public Key ID: E71B7545 On Thu, Nov 17, 2016, at 12:01 PM, Jani Nikula wrote: > On Thu, 17 Nov 2016, Rainer

Re: [Intel-gfx] [PATCH] drm/i915: Add a few more sanity checks for stolen handling

On 17 November 2016 at 15:58, Chris Wilson wrote: > We should never be called via obj->ops->release() on anything other than > a fully formed stolen object, so raise that to an assert. In the process > tidy up a comment and variable no longer used outside of a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a few more sanity checks for stolen handling

== Series Details == Series: drm/i915: Add a few more sanity checks for stolen handling URL : https://patchwork.freedesktop.org/series/15507/ State : success == Summary == Series 15507v1 drm/i915: Add a few more sanity checks for stolen handling

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only dump dp_m2_n2 configuration when drrs is used

== Series Details == Series: drm/i915: Only dump dp_m2_n2 configuration when drrs is used URL : https://patchwork.freedesktop.org/series/15505/ State : success == Summary == Series 15505v1 drm/i915: Only dump dp_m2_n2 configuration when drrs is used

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove misinformation about mark_busy/mark_idle

== Series Details == Series: drm/i915: Remove misinformation about mark_busy/mark_idle URL : https://patchwork.freedesktop.org/series/15504/ State : success == Summary == Series 15504v1 drm/i915: Remove misinformation about mark_busy/mark_idle

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm: Define drm_mm_for_each_node_in_range() (rev2)

== Series Details == Series: series starting with drm: Define drm_mm_for_each_node_in_range() (rev2) URL : https://patchwork.freedesktop.org/series/15489/ State : failure == Summary == Series 15489v2 Series without cover letter

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Pipe config debug dump diet

On Thu, Nov 17, 2016 at 03:13:55PM +, Tvrtko Ursulin wrote: > > On 17/11/2016 13:16, Patchwork wrote: > > == Series Details == > > > > Series: Pipe config debug dump diet > > URL : https://patchwork.freedesktop.org/series/15493/ > > State : success > > > > == Summary == > > > > Series

[Intel-gfx] [PATCH 29/32] drm/i915: Use drm_framebuffer_plane_{width, height}() where possible

From: Ville Syrjälä Replace drm_format_plane_{width,height}() usage with drm_framebuffer_plane_{width,height}() to avoid the lookup of the format info. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 27/32] drm/i915: Replace drm_format_num_planes() with fb->format->num_planes

From: Ville Syrjälä No need to look up the format info to get the number of planes, just use fb->format->num_planes directly. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 25/32] drm/i915: Store a pointer to the pixel format info for fbc

From: Ville Syrjälä Rather than store the pixel format and look up the format info as needed, let's just store a pointer to the format info directly and speed up our lookups. Cc: Paulo Zanoni Cc: intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 17/32] drm/i915: Set fb->dev early on for inherited fbs

From: Ville Syrjälä We want the fbs inherited from the BIOS to be more or less fully working prior to actually registering them. This will allow us to just pass the fb to various helper function instead of having to pass all the different parameters separately.

[Intel-gfx] [PATCH 21/32] drm/i915: Populate fb->format early for inherited fbs

From: Ville Syrjälä MAke sure the framebuffer format info is available as early as possible for fbs we inherit from the BIOS. This will allow us to use the fb as if it was fully formed before we register it. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Ville

[Intel-gfx] [PATCH 01/32] drm/i915: Add local 'fb' variables

From: Ville Syrjälä Add a local 'fb' variable to a few places to get rid of the 'crtc->primary->fb' stuff. Looks neater and helps me with my poor coccinelle skills later. While at it switch over to using the pixel format rather than depth+bpp. Cc:

[Intel-gfx] [PATCH 00/32] drm: Deduplicate fb format information

From: Ville Syrjälä This series aims to remove the duplicated format information stored under drm_framebuffer (depth,bits_per_pixel,pixel_format), and instead we just use the drm_format_info structure. And we store a pointer to the approriate drm_format_info under

Re: [Intel-gfx] [PATCH i-g-t v6 08/21] tests/sw_sync: Add subtest test_sync_merge_same

On Thu, Nov 17, 2016 at 10:01:56AM -0500, robert.f...@collabora.com wrote: > From: Robert Foss > > This subtest verifies merging a fence with itself does not fail. > > Signed-off-by: Robert Foss > Reviewed-by: Eric Engestrom

Re: [Intel-gfx] [PATCH i-g-t v6 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

On Thu, Nov 17, 2016 at 10:02:07AM -0500, robert.f...@collabora.com wrote: > From: Robert Foss > > Add subtest test_sync_merge_invalid that tests merging invalid fences. > > Signed-off-by: Robert Foss > --- > tests/sw_sync.c | 41

Re: [Intel-gfx] [PATCH i-g-t v6 02/21] tests/sw_sync: Add sw_sync test

On Thu, Nov 17, 2016 at 10:01:50AM -0500, robert.f...@collabora.com wrote: > From: Robert Foss > > Add initial tests for sw_sync. > > Signed-off-by: Robert Foss > Signed-off-by: Gustavo Padovan >

[Intel-gfx] [drm-intel:drm-intel-next-queued 2/2] drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: warning: unused variable 'ggtt'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d commit: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d [2/2] drm/i915: Remove stolen object spam config: i386-defconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0

Re: [Intel-gfx] [PATCH i-g-t v6 07/21] tests/sw_sync: Add subtest test_sync_merge

On Thu, Nov 17, 2016 at 10:01:55AM -0500, robert.f...@collabora.com wrote: > From: Robert Foss > > Add subtest test_sync_merge that tests merging fences and the validity of the > resulting merged fence. > > Signed-off-by: Robert Foss >

Re: [Intel-gfx] [PATCH i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

On Thu, 2016-11-17 at 15:39 +, Chris Wilson wrote: > On Thu, Nov 17, 2016 at 10:02:02AM -0500, robert.f...@collabora.com > wrote: > > > > From: Rafael Antognolli > > > > This test creates an already expired fence, then creates a merged > > fence > > out of that

[Intel-gfx] [PATCH] drm/i915: Only dump dp_m2_n2 configuration when drrs is used

From: Tvrtko Ursulin Otherwise it is just an useless empty line. Signed-off-by: Tvrtko Ursulin Suggested-by: Maarten Lankhorst Cc: Maarten Lankhorst ---

Re: [Intel-gfx] [PATCH i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

On Thu, Nov 17, 2016 at 10:02:02AM -0500, robert.f...@collabora.com wrote: > From: Rafael Antognolli > > This test creates an already expired fence, then creates a merged fence > out of that expired one (passed twice to the merge operation), and > finally closes the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Waterproof verification of gen9 forcewake table ranges

On 17/11/2016 15:16, Patchwork wrote: == Series Details == Series: drm/i915: Waterproof verification of gen9 forcewake table ranges URL : https://patchwork.freedesktop.org/series/15496/ State : warning == Summary == Series 15496v1 drm/i915: Waterproof verification of gen9 forcewake table

[Intel-gfx] [PATCH] drm/i915: Remove misinformation about mark_busy/mark_idle

Nowadays these are solely for managing the GT wakelock. Don't confuse the reader by referring to how they used to work, nor suggest they are deprecated simply because they are no longer relevant for frontbuffer tracking. Signed-off-by: Chris Wilson Cc: Daniel Vetter

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Waterproof verification of gen9 forcewake table ranges

== Series Details == Series: drm/i915: Waterproof verification of gen9 forcewake table ranges URL : https://patchwork.freedesktop.org/series/15496/ State : warning == Summary == Series 15496v1 drm/i915: Waterproof verification of gen9 forcewake table ranges

Re: [Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

On ma, 2016-11-14 at 21:51 +0200, Vivi, Rodrigo wrote: > On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote: > > On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote: > > > According to Bspec we need to > > > "Poll for PORT_REF_DW3_A grc_done == 1b" > > > only on ports B and C initialization

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Pipe config debug dump diet

On 17/11/2016 13:16, Patchwork wrote: == Series Details == Series: Pipe config debug dump diet URL : https://patchwork.freedesktop.org/series/15493/ State : success == Summary == Series 15493v1 Pipe config debug dump diet

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks

On Tue, Nov 15, 2016 at 02:53:00PM +0100, Maarten Lankhorst wrote: > Op 15-11-16 om 14:41 schreef Ville Syrjälä: > > On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote: > >> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com: > >>> From: Ville Syrjälä

[Intel-gfx] [PATCH i-g-t v6 13/21] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

From: Robert Foss This subtest runs a single consumer thread and multiple producer thread that are synchronized using multiple timelines. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 139

[Intel-gfx] [PATCH i-g-t v6 20/21] tests/sw_sync: Add subtest test_sync_busy_fork

From: Robert Foss Add subtest test_sync_busy_fork which increments the timeline in a forked child process. Signed-off-by: Robert Foss --- tests/sw_sync.c | 39 +++ 1 file changed, 39 insertions(+) diff

[Intel-gfx] [PATCH i-g-t v6 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

From: Robert Foss Add subtest test_sync_merge_invalid that tests merging invalid fences. Signed-off-by: Robert Foss --- tests/sw_sync.c | 41 + 1 file changed, 41 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t v6 08/21] tests/sw_sync: Add subtest test_sync_merge_same

From: Robert Foss This subtest verifies merging a fence with itself does not fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 27 +++ 1 file changed, 27

[Intel-gfx] [PATCH i-g-t v6 18/21] tests/sw_sync: Add igt_require check for sw_sync feature

From: Robert Foss Make sure that this test is skipped if the sw_sync feature is missing from the host system. Signed-off-by: Robert Foss --- lib/sw_sync.c | 1 + tests/sw_sync.c | 3 +++ 2 files changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t v6 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled

From: Robert Foss Add subtest test_timeline_closed_signaled that verifies that a signaled fence stays signaled after its timeline has been closed. Signed-off-by: Robert Foss --- tests/sw_sync.c | 18 ++ 1 file changed, 18

[Intel-gfx] [PATCH i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

From: Rafael Antognolli This test creates an already expired fence, then creates a merged fence out of that expired one (passed twice to the merge operation), and finally closes the merged fence. It shows that if the refcounts are wrong on the original expired fence,

[Intel-gfx] [PATCH i-g-t v6 17/21] lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support

From: Robert Foss Add igt_require_sw_sync to provide tests to skip if sw_sync support isn't available on the host machine. Signed-off-by: Robert Foss --- lib/sw_sync.c | 22 ++ lib/sw_sync.h | 1 + 2 files changed, 23

[Intel-gfx] [PATCH i-g-t v6 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket

From: Robert Foss Add subtest test_sync_busy_fork which increments the timeline in a forked child process, where the timeline fd has been sent through a UNIX socket. Signed-off-by: Robert Foss --- tests/sw_sync.c | 103

[Intel-gfx] [PATCH i-g-t v6 11/21] tests/sw_sync: Add subtest test_sync_random_merge

From: Robert Foss This subtest verifies that creating many timelines and merging random fences from each timeline with eachother results in merged fences that are fully functional. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom

[Intel-gfx] [PATCH i-g-t v6 05/21] tests/sw_sync: Add subtest test_alloc_merge_fence

From: Robert Foss This subtest verifies that merging two fences works in the simples possible case. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 23 +++ 1 file

[Intel-gfx] [PATCH i-g-t v6 15/21] tests/sw_sync: Add subtest test_timeline_closed

From: Robert Foss This subtest verifies that the fences of a timeline are not signalled when a timelne is closed. Signed-off-by: Robert Foss --- tests/sw_sync.c | 17 + 1 file changed, 17 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t v6 07/21] tests/sw_sync: Add subtest test_sync_merge

From: Robert Foss Add subtest test_sync_merge that tests merging fences and the validity of the resulting merged fence. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 67

[Intel-gfx] [PATCH i-g-t v6 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer

From: Robert Foss This subtest verifies the access ordering of multiple consumer threads. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 103

[Intel-gfx] [PATCH i-g-t v6 12/21] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

From: Robert Foss This subtest verifies that waiting, timing out on a wait and that counting fences in various states works. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 66

  1   2   >