Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote: > +static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc, > + uint32_t *batch, > + uint32_t dst_handle, > + uint32_t size, > +

Re: [Intel-gfx] drm modeset identifiers and xf86-video-intel

> Date: Thu, 7 Apr 2016 21:49:22 +0100 > From: Chris Wilson > > On Thu, Apr 07, 2016 at 08:20:15PM +0200, Mark Kettenis wrote: > > On OpenBSD I implemented idr_alloc() to return random IDs. While the > > xf86-video-modesetting driver is perfectly happy with this, the >

Re: [Intel-gfx] [PATCH 11/16] drm/i915/bxt: Don't toggle power well 1 on-demand

On Fri, Apr 01, 2016 at 04:02:42PM +0300, Imre Deak wrote: > Power well 1 is managed by the DMC firmware so don't toggle it on-demand > from the driver. This means we need to follow the BSpec display > initialization sequence during driver loading and resuming (both system > and runtime) and

Re: [Intel-gfx] [PATCH 13/16] drm/i915/bxt: Don't reprogram an already enabled DDI PHY

On Fri, Apr 01, 2016 at 04:02:44PM +0300, Imre Deak wrote: > If BIOS has already programmed and enabled a PHY, don't reprogram it as > that may interfere with the currently active outputs. A follow-up patch > will add state verification, so we can catch any misconfiguration on > BIOS's behalf. >

Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

On pe, 2016-04-08 at 21:12 +0300, Imre Deak wrote: > On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote: > > On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote: > > > This register is read-only, so we have never actually set > > > OCL2_LDOFUSE_PWR_DIS in it as specified by the

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

On Fri, 8 Apr 2016 18:17:51 +0100 Lionel Landwerlin wrote: > Color management properties are a bit of an odd use case because > they're not marked as atomic properties. Currently we're not updating > the non atomic values so the drm_crtc_state is out of sync with

Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote: > On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote: > > This register is read-only, so we have never actually set > > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a > > code > > comment about this. I filed a

Re: [Intel-gfx] [PATCH 09/16] drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpers

On Fri, Apr 01, 2016 at 04:02:40PM +0300, Imre Deak wrote: > For internal APIs passing dev_priv is preferred to reduce indirections, > so convert over a few DDI PHY, CDCLK helpers. > > No functional change. > > Signed-off-by: Imre Deak Acked-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote: > This register is read-only, so we have never actually set > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code > comment about this. I filed a specification update request to clarify > this there. Hmm. Interesting.

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

On Fri, 8 Apr 2016 18:21:51 +0100 Lionel Landwerlin wrote: > Hi Paul, > > Unfortunate that we've been writing the same patch at the same time :( > I think this we've got pretty much the same fix, but it probably needs > to be done at the DRM level, because this can

Re: [Intel-gfx] [PATCH 02/16] drm/i915/bxt: Fix GRC code register field definitions

On pe, 2016-04-08 at 20:22 +0300, Ville Syrjälä wrote: > On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote: > > This has been corrected in BSpec quite some time ago, but we missed > > it > > somehow. The wrong field definitions resulted in configuring PHY0 > > with > > an incorrect GRC

Re: [Intel-gfx] [PATCH 02/16] drm/i915/bxt: Fix GRC code register field definitions

On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote: > This has been corrected in BSpec quite some time ago, but we missed it > somehow. The wrong field definitions resulted in configuring PHY0 with > an incorrect GRC value. > > CC: Arthur J Runyan >

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

Hi Paul, Unfortunate that we've been writing the same patch at the same time :( I think this we've got pretty much the same fix, but it probably needs to be done at the DRM level, because this can impact other drivers too. Cheers, - Lionel On 08/04/16 17:26, Bob Paauwe wrote: The i915

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

Hi Paul, Unfortunate that we've been writing the same patch at the same time :( I think this we've got pretty much the same fix, but it probably needs to be done at the DRM level, because this can impact other drivers too. Cheers, - Lionel On 08/04/16 17:26, Bob Paauwe wrote: The i915

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

Color management properties are a bit of an odd use case because they're not marked as atomic properties. Currently we're not updating the non atomic values so the drm_crtc_state is out of sync with the values stored in the crtc object. Cc: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set legacy properties when using legacy gamma set IOCTL.

== Series Details == Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL. URL : https://patchwork.freedesktop.org/series/5466/ State : failure == Summary == Series 5466v1 drm/i915: Set legacy properties when using legacy gamma set IOCTL.

[Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

The MOCS registers were added in Gen9 and define the caching policy. The registers are split into two sets. The first set controls the EDRAM policy and have a set for each engine, the second set controls the L3 policy. The two sets use the same index. The RCS registers and the L3CC registers are

[Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

We are currently missing the color management update condition to commit planes on crtc. Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) Cc: Maarten Lankhorst Cc: Jani Nikula Cc: Daniel Vetter

[Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

The i915 driver is now using atomic properties and atomic commit to handle the legacy set gamma IOCTL. However, if the driver is configured without atomic (nuclear_pageflip = false), it won't update the legacy properties for degamma_lut, gamma_lut and ctm leaving them out of sync with the atomic

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

== Series Details == Series: drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI URL : https://patchwork.freedesktop.org/series/5462/ State : failure == Summary == Series 5462v1 drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

On Fri, Apr 08, 2016 at 06:01:41PM +0300, Jani Nikula wrote: > On Fri, 08 Apr 2016, Ville Syrjälä wrote: > > On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote: > >> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: > >> > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

On Fri, 2016-04-08 at 17:11 +0300, Ville Syrjälä wrote: > On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote: > > The function chv_data_lane_soft_reset() uses the lane count to decide > > which lanes to set/reset. However, the HDMI code never sets lane count, > > since it

[Intel-gfx] [PATCH 0/6] Unduplicate CHV phy code

There was a lot of duplication between the CHV specific code in DP and HDMI encoders. This series moves those to a new file: intel_dpio_phy.c. I don't really know all the details about that code, so couldn't come up with decent names for the new funcions. Perhaps Ville can suggest something

[Intel-gfx] [PATCH 5/6] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

The only difference between the DP and HDMI versions was the lane count. Since lane_count is now set appropriately for HDMI too, get rid of the duplication and move this to intel_dpio_phy.c Signed-off-by: Ander Conselvan de Oliveira ---

[Intel-gfx] [PATCH 4/6] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

The same logic is used for DP and HDMI so move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 83 +--

[Intel-gfx] [PATCH 3/6] drm/i915: Unduplicate chv_data_lane_soft_reset()

The function chv_data_lane_soft_reset() was duplicated in DP and HDMI code. Move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 44

[Intel-gfx] [PATCH 2/6] drm/i915: Unduplicate CHV signal level code

The code for programming voltage swing and emphasis was duplicated between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/Makefile | 1 +

[Intel-gfx] [PATCH 6/6] drm/i915: Undiplicate CHV encoders' post pll disable code

The exact same code was used by HDMI and DP encoders, so move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 30 +-

[Intel-gfx] [PATCH 1/6] drm/i915: Set crtc_state->lane_count for HDMI

Set the lane count for HDMI to 4. This will make it easier to unduplicate CHV phy code. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

On Fri, 08 Apr 2016, Ville Syrjälä wrote: > On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote: >> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > We've had problems on several

Re: [Intel-gfx] [RFC 1/4] drm/i915: Move releasing of the GEM request from free to retire/cancel

On Fri, Apr 08, 2016 at 02:54:55PM +0100, Tvrtko Ursulin wrote: > From: Chris Wilson > > If we move the release of the GEM request (i.e. decoupling it from the > various lists used for client and context tracking) after it is complete > (either by the GPU retiring the

[Intel-gfx] [PATCH] drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

The whole file is ignored on CONFIG_ACPI=n. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_opregion.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote: > On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We've had problems on several occasions with using the panel type > > from the VBT block 40. Usually it seems to

Re: [Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote: > @@ -615,11 +613,6 @@ static void execlists_context_queue(struct > drm_i915_gem_request *request) > struct drm_i915_gem_request *cursor; > int num_elements = 0; > > - if (request->ctx !=

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix CHV data lane soft reset for HDMI

== Series Details == Series: drm/i915: Fix CHV data lane soft reset for HDMI URL : https://patchwork.freedesktop.org/series/5461/ State : warning == Summary == Series 5461v1 drm/i915: Fix CHV data lane soft reset for HDMI http://patchwork.freedesktop.org/api/1.0/series/5461/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We've had problems on several occasions with using the panel type > from the VBT block 40. Usually it seems to be 2, which often > doesn't give us the correct timings for the panel.

Re: [Intel-gfx] [RFC 3/4] drm/i915: Use new i915_gem_object_pin_map for LRC

On Fri, Apr 08, 2016 at 02:54:57PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We can use the new pin/lazy unpin API for more performance > in the execlist submission paths. The sticking point for me was the ringbuffer and Braswell having to re-ioremap it

Re: [Intel-gfx] [RFC 2/4] drm/i915/guc: Keep the previous context pinned until the next one has been completed

On Fri, Apr 08, 2016 at 02:54:56PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In GuC mode submitting requests is only putting them into the > GuC queue with the actual submission to hardware following at > some future point. This makes the per engine last context

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_type

On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Store the extracted panel_type under dev_priv.vbt instead of keeping > around a static variable for it. > > Cc: Rob Kramer > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Reject panel_type > 0xf from VBT

On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > VBT can only contain 16 panel entries, indexed with the panel_type. > To play it safe we should reject panel_type > 0xf, so that we don't > read past the valid data. > > Cc: Rob

Re: [Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote: > The function chv_data_lane_soft_reset() uses the lane count to decide > which lanes to set/reset. However, the HDMI code never sets lane count, > since it always uses the four lanes of the phy. Note that before commit >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT

On Fri, Apr 08, 2016 at 01:56:15PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT > URL : https://patchwork.freedesktop.org/series/5458/ > State : failure > > == Summary == > > Series 5458v1 Series without cover

[Intel-gfx] ✗ Fi.CI.BAT: failure for Eliminating the execlist retired request queue

== Series Details == Series: Eliminating the execlist retired request queue URL : https://patchwork.freedesktop.org/series/5459/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_dpll_mgr.o CC [M] drivers/gpu/drm/i915/intel_fbc.o CC [M]

[Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

The function chv_data_lane_soft_reset() uses the lane count to decide which lanes to set/reset. However, the HDMI code never sets lane count, since it always uses the four lanes of the phy. Note that before commit a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), all lanes were

[Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

From: Tvrtko Ursulin With the previous patch having extended the pinned lifetime of contexts by referencing the previous context from the current request until the latter is retired (completed by the GPU), we can now remove usage of execlist retired queue entirely. This is

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT

== Series Details == Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT URL : https://patchwork.freedesktop.org/series/5458/ State : failure == Summary == Series 5458v1 Series without cover letter

[Intel-gfx] [RFC 1/4] drm/i915: Move releasing of the GEM request from free to retire/cancel

From: Chris Wilson If we move the release of the GEM request (i.e. decoupling it from the various lists used for client and context tracking) after it is complete (either by the GPU retiring the request, or by the caller cancelling the request), we can remove the

[Intel-gfx] [RFC 0/4] Eliminating the execlist retired request queue

From: Tvrtko Ursulin Retired request queue coupled with retired work handler is a scalability concern on some workloads of which one dramatic example is gem_close_race. This series depend on i915_gem_object_pin_map series by Chris Wilson. Brief outline of patches:

[Intel-gfx] [RFC 3/4] drm/i915: Use new i915_gem_object_pin_map for LRC

From: Tvrtko Ursulin We can use the new pin/lazy unpin API for more performance in the execlist submission paths. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 15 +++ 1 file changed, 7 insertions(+), 8

[Intel-gfx] [RFC 2/4] drm/i915/guc: Keep the previous context pinned until the next one has been completed

From: Tvrtko Ursulin In GuC mode submitting requests is only putting them into the GuC queue with the actual submission to hardware following at some future point. This makes the per engine last context tracking insufficient for closing the premature context unpin race.

[Intel-gfx] [PATCH 1/3] drm/i915: Reject panel_type > 0xf from VBT

From: Ville Syrjälä VBT can only contain 16 panel entries, indexed with the panel_type. To play it safe we should reject panel_type > 0xf, so that we don't read past the valid data. Cc: Rob Kramer Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 2/3] drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_type

From: Ville Syrjälä Store the extracted panel_type under dev_priv.vbt instead of keeping around a static variable for it. Cc: Rob Kramer Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

From: Ville Syrjälä We've had problems on several occasions with using the panel type from the VBT block 40. Usually it seems to be 2, which often doesn't give us the correct timings for the panel. After some more digging I found a way to get a panel type via the

Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

Hi, On 11-03-16 11:07, Timo Aaltonen wrote: 29.02.2016, 16:47, Hans de Goede kirjoitti: sna has no meaningfull accel for gen9+, this causes problems with i.e. apps using XVideo since the sprite XVideo support does not work well for many apps. Therefor it is better to just let the xserver fall

[Intel-gfx] ✓ Fi.CI.BAT: success for edram size calculation

== Series Details == Series: edram size calculation URL : https://patchwork.freedesktop.org/series/5457/ State : success == Summary == Series 5457v1 edram size calculation http://patchwork.freedesktop.org/api/1.0/series/5457/revisions/1/mbox/ Test gem_exec_basic: Subgroup basic-bsd:

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/bxt: Corrected the guid for bxt.

On Fri, Apr 08, 2016 at 12:00:22PM +0300, Jani Nikula wrote: > On Thu, 07 Apr 2016, Animesh Manna wrote: > > Guid is changed for bxt platform, so corrected the guid for bxt. > > > > Signed-off-by: Ananth Krishna R > > Signed-off-by: Bharath K

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

== Series Details == Series: series starting with [v2,1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf URL : https://patchwork.freedesktop.org/series/5454/ State : warning == Summary == Series 5454v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Store and use edram capabilities

On Fri, Apr 08, 2016 at 02:54:04PM +0300, Mika Kuoppala wrote: > Store the edram capabilities instead of only the size of > edram. This is preparatory patch to allow edram size calculation > based on edram capability bits for gen9+. With gen9 the > edram is behind llc and is a separate entity.

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Don't program eLLC IDI hash mask for gen9+

On Fri, Apr 08, 2016 at 02:54:03PM +0300, Mika Kuoppala wrote: > For gen9 onwards, eDRAM is a true memory side cache. So > there is no need to program idi has mask as it is for eLLC > only. > > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 2 +-

[Intel-gfx] [PATCH 0/3] edram size calculation

The skl I have reported wrong amount in dmesg. Mika Kuoppala (3): drm/i915: Don't program eLLC IDI hash mask for gen9+ drm/i915: Store and use edram capabilities drm/i915: Calculate edram size drivers/gpu/drm/i915/i915_debugfs.c | 5 ++-- drivers/gpu/drm/i915/i915_drv.h | 7 +++--

[Intel-gfx] [PATCH 3/3] drm/i915: Calculate edram size

With gen9+ the edram capabilities are defined so that we can calculate the edram (ellc) size accordingly. Note that there are undefined combinations for some subset of edram capability bits. Return the closest size for undefined indexes. Even if we get it wrong with beginning of future gen

[Intel-gfx] [PATCH 1/3] drm/i915: Don't program eLLC IDI hash mask for gen9+

For gen9 onwards, eDRAM is a true memory side cache. So there is no need to program idi has mask as it is for eLLC only. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 2/3] drm/i915: Store and use edram capabilities

Store the edram capabilities instead of only the size of edram. This is preparatory patch to allow edram size calculation based on edram capability bits for gen9+. With gen9 the edram is behind llc and is a separate entity. With hsw/bdw it was more of a victim cache for LLC so the name 'eLLC'

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/bxt: Block D3 during suspend.

On Thu, Apr 07, 2016 at 08:22:11PM +0530, Animesh Manna wrote: > For BXT, display engine can not generate interrupt when in D3. > On the othen hand S0ix can be achieved without display in D3. So, other > Display should not put into D3 for HPD to work and will not > have any power impact. > >

[Intel-gfx] [PATCH v2 2/6] drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj

After we pin the ringbuffer into the GGTT, all error paths need to unpin it again. Move this common step into one block, and make the unable to iomap error code consistent (i.e. treat it as out of memory to avoid confusing it with a invalid argument). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. v2: Start using is_vmalloc_addr() Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

[Intel-gfx] vmap consolidation to obj->mapping

Now with a new lick of paint, I introduce the cached obj->mapping pointer for all your contiguous accesses! Enjoy, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

We only need the struct_mutex to manipulate the pages_pin_count on the object, we do not need to hold our BKL when freeing the exported scatterlist. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v2 5/6] drm,i915: Introduce drm_malloc_gfp()

I have instances where I want to use drm_malloc_ab() but with a custom gfp mask. And with those, where I want a temporary allocation, I want to try a high-order kmalloc() before using a vmalloc(). So refactor my usage into drm_malloc_gfp(). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 3/6] drm/i915: Refactor duplicate object vmap functions

We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the mapping into the obj->pages lifetime, then we can reuse an obj->mapping for both and at the same time couple it into the shrinker. There is a third vmapping routine in the

[Intel-gfx] [PATCH v2 6/6] drm/i915: Avoid allocating a vmap arena for a single page

If we want a contiguous mapping of a single page sized object, we can forgo using vmap() and just use a regular kmap(). Note that this is only suitable if the desired pgprot_t is compatible. v2: Use is_vmalloc_addr() Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/6] drm/i915: remove IS_ERR_OR_NULL check

On Fri, Apr 08, 2016 at 10:32:29AM +0100, Matthew Auld wrote: > A call to i915_gem_alloc_object can only ever return NULL in the event > of an error. We are planning to report the real error back. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 4/6] drm/i915: handle potential overflow

On Fri, Apr 08, 2016 at 10:32:32AM +0100, Matthew Auld wrote: > Much like with the equivalent gen8_alloc_va_range. Just delete the warn and make the allocation paths stronger if you feel paranoid. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 2/6] drm/i915: reference ppgtt->base.dev directly

On pe, 2016-04-08 at 10:32 +0100, Matthew Auld wrote: > Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt. > > Cc: Joonas Lahtinen > Signed-off-by: Matthew Auld > --- >  drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++--- >  1 file

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: remove IS_ERR_OR_NULL check

== Series Details == Series: series starting with [1/6] drm/i915: remove IS_ERR_OR_NULL check URL : https://patchwork.freedesktop.org/series/5453/ State : failure == Summary == Series 5453v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5453/revisions/1/mbox/

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1

== Series Details == Series: drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1 URL : https://patchwork.freedesktop.org/series/5438/ State : failure == Summary == Series 5438v1 drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1

Re: [Intel-gfx] [PATCH v2 2/3] drm/dp/mst: Enhance DP MST debugfs output

On Thu, 07 Apr 2016, Jim Bride wrote: > Add some additional information (input vs. output port, sink associated > with VC, peer device type, max number of VCs supported) and ensure that > any embedded '\0' characters in a branch device's devid string are not > written

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move modeset state checker calls.

Op 08-04-16 om 01:23 schreef Matt Roper: > On Wed, Mar 23, 2016 at 02:58:07PM +0100, Maarten Lankhorst wrote: >> The modeset state checker no longer has full access to the hardware, >> instead it should only check affected crtc's. >> >> Looking for disabled stuff can be checked immediately after

Re: [Intel-gfx] [PATCH v2 1/3] drm/edid: Add drm_edid_get_monitor_name()

On Thu, 07 Apr 2016, Jim Bride wrote: > In order to include monitor name information in debugfs > output we needed to add a function that would extract the > monitor name from the EDID, and that function needed to > reside in the file where the rest of the EDID helper

[Intel-gfx] [PATCH 4/6] drm/i915: handle potential overflow

Much like with the equivalent gen8_alloc_va_range. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 5/6] drm/i915: bail in alloc_pdp when !FULL_48BIT_PPGTT

If we are not in FULL_48BIT_PPGTT mode then we really shouldn't continue on with our allocations, given that the call to free_dpd would bail early without freeing everything, thus leaking memory. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld

[Intel-gfx] [PATCH 6/6] drm/i915: call kunmap_px on pt_vaddr

We need to kunmap pt_vadrr and not pt itself, otherwise we end up mapping a bunch of pages without ever unmapping them. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 2/6] drm/i915: reference ppgtt->base.dev directly

Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH 3/6] drm/i915: combine overflow checks

Looks a little neater and ever so slightly reduces the size of the binary. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 1/6] drm/i915: remove IS_ERR_OR_NULL check

A call to i915_gem_alloc_object can only ever return NULL in the event of an error. Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915/bxt: add bxt dsi gpio element support

On Thu, 07 Apr 2016, kbuild test robot wrote: > Hi Jani, > > [auto build test ERROR on drm-intel/for-linux-next] > [cannot apply to v4.6-rc2 next-20160407] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: >

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/bxt: Corrected the guid for bxt.

On Thu, 07 Apr 2016, Animesh Manna wrote: > Guid is changed for bxt platform, so corrected the guid for bxt. > > Signed-off-by: Ananth Krishna R > Signed-off-by: Bharath K Veera > Signed-off-by: Animesh Manna

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of manual container_of (rev2)

== Series Details == Series: series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of manual container_of (rev2) URL : https://patchwork.freedesktop.org/series/5403/ State : failure == Summary == Series 5403v2 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On Fri, Apr 08, 2016 at 07:02:35AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent > forcewake auto-release timeout across kernel configs > URL : https://patchwork.freedesktop.org/series/5424/ > State : failure > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Minor i915_dp_mst_info output enhancements (rev2)

== Series Details == Series: Minor i915_dp_mst_info output enhancements (rev2) URL : https://patchwork.freedesktop.org/series/5346/ State : failure == Summary == Series 5346v2 Minor i915_dp_mst_info output enhancements http://patchwork.freedesktop.org/api/1.0/series/5346/revisions/2/mbox/

Re: [Intel-gfx] [RFC] Convert INTEL_INFO(...)->gen to INTEL_GEN(...)

On Thu, 07 Apr 2016, Dave Gordon wrote: > Since Jani has given us this macro, I thought I'd make use of it by > converting all existing instances of this construct with a really > simple little Coccinelle script: > > @intel_gen@ > expression E; > @@ > <... > -

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fixes and workarounds for GuC/doorbell setup

== Series Details == Series: Fixes and workarounds for GuC/doorbell setup URL : https://patchwork.freedesktop.org/series/5426/ State : failure == Summary == Series 5426v1 Fixes and workarounds for GuC/doorbell setup http://patchwork.freedesktop.org/api/1.0/series/5426/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

On Thu, 2016-04-07 at 09:20 -0700, Jim Bride wrote: > On Thu, Apr 07, 2016 at 11:15:38AM +0300, Ander Conselvan De Oliveira wrote: > > On Wed, 2016-04-06 at 16:00 -0700, Jim Bride wrote: > > > In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some > > > much needed clean-up was done,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen (rev2)

== Series Details == Series: drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen (rev2) URL : https://patchwork.freedesktop.org/series/5407/ State : failure == Summary == CC [M] drivers/net/usb/cdc_ncm.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M]

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

== Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs URL : https://patchwork.freedesktop.org/series/5424/ State : failure == Summary == Series 5424v1 Series without cover letter

Re: [Intel-gfx] [CI-ping 1/9] drm/i915: Include engine->last_submitted_seqno in GPU error state

Yesterday CI got lagged for a bit while I was tuning timeouts in host connectivity. We're now using nmap (instead of ping) to get better results over firewalls and long distances. Change sparked from connecting French DUT to our Jenkins. The results for this series were run, but not posted for

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI-ping,1/9] drm/i915: Include engine->last_submitted_seqno in GPU error state

== Series Details == Series: series starting with [CI-ping,1/9] drm/i915: Include engine->last_submitted_seqno in GPU error state URL : https://patchwork.freedesktop.org/series/5400/ State : failure == Summary == Series 5400v1 Series without cover letter

Re: [Intel-gfx] [RFC] Prefer INTEL_INFO(dev_priv) to INTEL_INFO(dev)

On to, 2016-04-07 at 18:57 +0100, Dave Gordon wrote: > Where we have a suitable dev_priv pointer, we can use that rather than > 'dev' for accessing INTEL_INFO().  This removes one level of memory > reference, decreasing code size a little and possibly making everything > a little faster. We could