[Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting was changed to only capture on error path, but we need to set it properly in normal path too, otherwise we'll fail to complete workload which could lead guest VM vGPU reset. Cc: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Set the Z inversion overlap field

== Series Details == Series: drm/i915: Set the Z inversion overlap field URL : https://patchwork.freedesktop.org/series/14704/ State : warning == Summary == Series 14704v1 drm/i915: Set the Z inversion overlap field https://patchwork.freedesktop.org/api/1.0/series/14704/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: Set the Z inversion overlap field

Dual link Z-inversion overlap field is present in MIPI_CTRL register unlike the older platforms, hence setting the same in this patch. Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_dsi.c | 17 + 2 files

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

On Tue, Nov 01, 2016 at 12:34:37PM -0700, Manasi Navare wrote: > On Tue, Nov 01, 2016 at 09:16:28PM +0200, Jani Nikula wrote: > > On Tue, 01 Nov 2016, Manasi Navare wrote: > > > On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote: > > >> On Sat, 29 Oct 2016,

[Intel-gfx] [PATCH 2/2] aubdump: Bump GTT size to 128MB.

You can easily run out of GTT space with the current fixed allocation of 64MB. Bump it to 128MB to avoid sporadic page-fault errors with the simulator. --- tools/aubdump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/aubdump.c b/tools/aubdump.c index

[Intel-gfx] [PATCH 1/2] aubdump: Fix GTT setup for Gen8+.

Gen8+ have 64 bit GTT entries, so we need to allocate twice as much space for the GTT table in order to cover the same number of GTT pages. Fixes sporadic page-fault crashes on the simulator. --- tools/aubdump.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff

Re: [Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass configuration through file descriptor

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Lionel Landwerlin >Sent: Tuesday, November 01, 2016 11:15 AM >To: intel-gfx@lists.freedesktop.org >Subject: [Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass >configuration

Re: [Intel-gfx] [PATCH v4 i-g-t 2/2] aubdump: add --command option to stream aubdump to another program

>-Original Message- >From: Landwerlin, Lionel G >Sent: Tuesday, November 01, 2016 11:15 AM >To: intel-gfx@lists.freedesktop.org >Cc: Landwerlin, Lionel G ; Gandikota, Sirisha > >Subject: [PATCH v4 i-g-t 2/2] aubdump: add --command

Re: [Intel-gfx] [PATCH] drm/i915: Move hangcheck code out from i915_irq.c

On Tue, Nov 01, 2016 at 06:43:03PM +0200, Mika Kuoppala wrote: > Create new file for hangcheck specific code, intel_hangcheck.c, > and move all related code in it. > > v2: s/intel_engine_hangcheck/intel_engine (Chris) > > No functional changes. > > Cc: Chris Wilson >

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

On Tue, 01 Nov 2016, "Pandiyan, Dhinakaran" wrote: > On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote: >> On Tue, 01 Nov 2016, Dhinakaran Pandiyan >> wrote: >> > According to BSpec, cdclk for BDW has to be not less than 432 MHz

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote: > On Tue, 01 Nov 2016, Dhinakaran Pandiyan > wrote: > > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP > > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less >

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

On Tue, 01 Nov 2016, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less > than 432 MHz, enabling audio leads to pipe FIFO underruns and

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

On Tue, Nov 01, 2016 at 09:16:28PM +0200, Jani Nikula wrote: > On Tue, 01 Nov 2016, Manasi Navare wrote: > > On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote: > >> On Sat, 29 Oct 2016, Manasi Navare wrote: > >> > If link training

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: BDW cdclk fix for DP audio

On Tue, 01 Nov 2016, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less > than 432 MHz, enabling audio leads to pipe FIFO underruns and

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

On Tue, 01 Nov 2016, Manasi Navare wrote: > On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote: >> On Sat, 29 Oct 2016, Manasi Navare wrote: >> > If link training at a link rate optimal for a particular >> > mode fails during

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio

== Series Details == Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio URL : https://patchwork.freedesktop.org/series/14688/ State : warning == Summary == Series 14688v1 Series without cover letter

[Intel-gfx] [PATCH v4 1/2] drm/i915/dp: BDW cdclk fix for DP audio

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. From BSpec: "Display» BDW-SKL» dpr» [Register] DP_TP_CTL

[Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. Let's apply this work around to GEN9 platforms too, as it

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move hangcheck code out from i915_irq.c

== Series Details == Series: drm/i915: Move hangcheck code out from i915_irq.c URL : https://patchwork.freedesktop.org/series/14685/ State : warning == Summary == Series 14685v1 drm/i915: Move hangcheck code out from i915_irq.c

[Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass configuration through file descriptor

This makes parsing options less complicated and easier to extend. v2: Fix device id parsing (atoi -> sscanf) (Sirisha) Combine with previous commit moving init function (Sirisha) v3: Fix behavior change between bash 4.3 & 4.4 in <<< with \n characters (Lionel) Signed-off-by: Lionel

[Intel-gfx] [PATCH v4 i-g-t 2/2] aubdump: add --command option to stream aubdump to another program

This comes handy if you want to look at your application output without having to save it into a file. For example, use this with aubinator from Mesa : $ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app v2: Fix handling empty command line option v3: Fix command line concatenation

Re: [Intel-gfx] [PATCH] drm/i915/huc: Update the construction of file path for HuC similar to that of GuC

>-Original Message- >From: Mcgee, Jeff >Sent: Tuesday, November 1, 2016 11:22 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [PATCH] drm/i915/huc: Update the construction of file path for HuC >similar to that of GuC > >On Mon, Oct

Re: [Intel-gfx] [PATCH] drm/i915/huc: Update the construction of file path for HuC similar to that of GuC

On Mon, Oct 31, 2016 at 03:24:53PM -0700, Anusha Srivatsa wrote: > Update the file construction and specifying the required version > similar to that of GuC.Add an extra field for the build number. > Adopted the approach used in > https://patchwork.freedesktop.org/patch/104355/ > > Cc: Jeff

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Move hangcheck code out from i915_irq.c

== Series Details == Series: series starting with [1/2] drm/i915: Move hangcheck code out from i915_irq.c URL : https://patchwork.freedesktop.org/series/14682/ State : warning == Summary == Series 14682v1 Series without cover letter

Re: [Intel-gfx] [PATCH v8 11/12] drm/i915: Add more Haswell OA metric sets

On Tue, Nov 1, 2016 at 2:57 PM, Chris Wilson wrote: > On Fri, Oct 28, 2016 at 03:14:29AM +0100, Robert Bragg wrote: > > This adds 'compute', 'compute extended', 'memory reads', 'memory writes' > > and 'sampler balance' metric sets for Haswell. > > > > The code is auto

[Intel-gfx] [PATCH] drm/i915: Move hangcheck code out from i915_irq.c

Create new file for hangcheck specific code, intel_hangcheck.c, and move all related code in it. v2: s/intel_engine_hangcheck/intel_engine (Chris) No functional changes. Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko Ursulin

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote: > > Merged to dinq, thanks for the review! Almost as bad as me in forgetting to add the r-b. dim save us! :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move hangcheck code out from i915_irq.c

Chris Wilson writes: > On Tue, Nov 01, 2016 at 06:03:21PM +0200, Mika Kuoppala wrote: >> Create new file for hangcheck specific code, intel_engine_hangcheck.c, >> and move all the related code in it. >> >> No functional changes. >> >> Cc: Chris Wilson

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

On 01/11/2016 16:16, Patchwork wrote: == Series Details == Series: drm/i915: Allow shrinking of userptr objects once again (rev2) URL : https://patchwork.freedesktop.org/series/14675/ State : warning == Summary == Series 14675v2 drm/i915: Allow shrinking of userptr objects once again

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3)

Patchwork writes: > == Series Details == > > Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3) > URL : https://patchwork.freedesktop.org/series/14620/ > State : warning > > == Summary == > > Series 14620v3 Series without cover letter

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

On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote: > On Sat, 29 Oct 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 1/2] drm/i915: Move hangcheck code out from i915_irq.c

On Tue, Nov 01, 2016 at 06:03:21PM +0200, Mika Kuoppala wrote: > Create new file for hangcheck specific code, intel_engine_hangcheck.c, > and move all the related code in it. > > No functional changes. > > Cc: Chris Wilson > Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move error state capture code out from i915_irq.c

On Tue, Nov 01, 2016 at 06:03:22PM +0200, Mika Kuoppala wrote: > We have a place already for error handling and error > state capture, i915_gpu_error.c. Move code to more > appropriate file. i915_gpu_error.c is conditionally compiled iff we want error capture. We need reset handling irrespective

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

== Series Details == Series: drm/i915: Allow shrinking of userptr objects once again (rev2) URL : https://patchwork.freedesktop.org/series/14675/ State : warning == Summary == Series 14675v2 drm/i915: Allow shrinking of userptr objects once again

[Intel-gfx] [PATCH 1/2] drm/i915: Move hangcheck code out from i915_irq.c

Create new file for hangcheck specific code, intel_engine_hangcheck.c, and move all the related code in it. No functional changes. Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Signed-off-by: Mika

[Intel-gfx] [PATCH 2/2] drm/i915: Move error state capture code out from i915_irq.c

We have a place already for error handling and error state capture, i915_gpu_error.c. Move code to more appropriate file. No functional changes. Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko Ursulin

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3)

== Series Details == Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3) URL : https://patchwork.freedesktop.org/series/14620/ State : warning == Summary == Series 14620v3 Series without cover letter

Re: [Intel-gfx] [i-g-t PATCH v1 08/14] lib: Add igt_create_bo_with_dimensions

Hi, On 02/03/16 14:00, Tomeu Vizoso wrote: igt_create_bo_with_dimensions() is intended to abstract differences between drivers in buffer object creation. The driver-specific ioctls will be called if the driver that is being tested can satisfy the needs of the calling subtest, or it will be

[Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to check for the config everywhere. Signed-off-by: Jani Nikula --- Just an idea on top of Patrik's patch. --- drivers/gpu/drm/arc/arcpgu_drv.c| 2 -- drivers/gpu/drm/arm/hdlcd_drv.c

Re: [Intel-gfx] [PATCH v2] drm/i915: Allow shrinking of userptr objects once again

On Tue, Nov 01, 2016 at 02:44:10PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects > are backed by swap") stopped considering the userptr objects > in shrinker callbacks. > > Restore that so idle

Re: [Intel-gfx] [PATCH v8 11/12] drm/i915: Add more Haswell OA metric sets

On Fri, Oct 28, 2016 at 03:14:29AM +0100, Robert Bragg wrote: > This adds 'compute', 'compute extended', 'memory reads', 'memory writes' > and 'sampler balance' metric sets for Haswell. > > The code is auto generated from an XML description of metric sets, > currently maintained in gputop, ref: >

Re: [Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

On Mon, Oct 31, 2016 at 08:56:34PM +, Chris Wilson wrote: > On Mon, Oct 31, 2016 at 10:36:59PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I pretty much just wanted to store struct intel_crtc * instead > > of struct drm_crtc * in

[Intel-gfx] [PATCH v2] drm/i915: Allow shrinking of userptr objects once again

From: Tvrtko Ursulin Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by swap") stopped considering the userptr objects in shrinker callbacks. Restore that so idle userptr objects can be discarded in order to free up memory. One change further

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

On Tue, Nov 01, 2016 at 02:29:39PM +, Tvrtko Ursulin wrote: > > On 01/11/2016 13:52, Chris Wilson wrote: > >On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

On 01/11/2016 13:52, Chris Wilson wrote: On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by swap") stopped considering the userptr objects in shrinker

Re: [Intel-gfx] [PATCH] drm/i915: Export a function to flush the context upon pinning

On Mon, Oct 31, 2016 at 03:28:08PM +, Matthew Auld wrote: > On 30 October 2016 at 13:28, Chris Wilson wrote: > > For legacy contexts we employ an optimisation to only flush the context > > when binding into the global GTT. This avoids stalling onthe GPU when > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

On Tue, Nov 01, 2016 at 01:46:00PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: A game of OCD dominoes > URL : https://patchwork.freedesktop.org/series/14634/ > State : warning > > == Summary == > > Series 14634v1 drm/i915: A game of OCD dominoes >

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects > are backed by swap") stopped considering the userptr objects > in shrinker callbacks. > > Restore that so idle

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

== Series Details == Series: drm/i915: A game of OCD dominoes URL : https://patchwork.freedesktop.org/series/14634/ State : warning == Summary == Series 14634v1 drm/i915: A game of OCD dominoes https://patchwork.freedesktop.org/api/1.0/series/14634/revisions/1/mbox/ Test kms_cursor_legacy:

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote: > Op 01-11-16 om 14:09 schreef Ville Syrjälä: > > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote: > >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to > >> replace the old

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

Op 01-11-16 om 14:09 schreef Ville Syrjälä: > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote: >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to >> replace the old for_each_xxx_in_state ones. This is useful for >1 flip >> depth and getting rid of all

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

Comparing pte index to a number of entries is wrong when clearing a range of pte entries. Use end marker of 'one past' to correctly point adequate number of ptes to the scratch page. v2: assert early instead of warning late (Chris) v3: removed consts (Joonas) Fixes: d209b9c3cd28 ("drm/i915/gtt:

[Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

From: Tvrtko Ursulin Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by swap") stopped considering the userptr objects in shrinker callbacks. Restore that so idle userptr objects can be discarded in order to free up memory. One change further

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Improve lockdep tracking for obj->mm.lock

== Series Details == Series: drm/i915: Improve lockdep tracking for obj->mm.lock URL : https://patchwork.freedesktop.org/series/14672/ State : warning == Summary == Series 14672v1 drm/i915: Improve lockdep tracking for obj->mm.lock

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote: > Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to > replace the old for_each_xxx_in_state ones. This is useful for >1 flip > depth and getting rid of all xxx->state dereferences. > > Signed-off-by: Maarten

Re: [Intel-gfx] [RESEND PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state

On Wed, Oct 19, 2016 at 03:55:38PM +0200, Maarten Lankhorst wrote: > This gets rid of a warning that the connectors are used without locking > when doing a nonblocking modeset. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

On Tue, Nov 01, 2016 at 02:40:35PM +0200, Ville Syrjälä wrote: > On Tue, Nov 01, 2016 at 09:57:43AM +0100, Maarten Lankhorst wrote: > > Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com: > > > From: Ville Syrjälä > > > > > > When we end up not recomputing

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Store the vma in an rbtree under the object

== Series Details == Series: drm/i915: Store the vma in an rbtree under the object URL : https://patchwork.freedesktop.org/series/14671/ State : warning == Summary == Series 14671v1 drm/i915: Store the vma in an rbtree under the object

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

On Tue, Nov 01, 2016 at 10:07:51AM +0100, Paul Bolle wrote: > On Tue, 2016-11-01 at 09:57 +0100, Maarten Lankhorst wrote: > > Otherwise looks sane, I have a similar patch in my tree. I didn't > > submit it yet but the fix was similar. Except for the > > dev_cdclk stuff. > > > > With the last

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

On Tue, Nov 01, 2016 at 09:57:43AM +0100, Maarten Lankhorst wrote: > Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > When we end up not recomputing the cdclk, we need to populate > > intel_state->cdclk with the

Re: [Intel-gfx] [PATCH v2.1 03/11] drm/i915/gen9+: Use for_each_intel_plane_on_crtc in skl_print_wm_changes, v2.

Em Ter, 2016-11-01 às 12:04 +0100, Maarten Lankhorst escreveu: > Using for_each_intel_plane_on_crtc will allow us to find all > allocations > that may have changed, not just the one added by the atomic state. > > This will print changes to plane allocations for crtc's when some > planes are not

Re: [Intel-gfx] [PATCH] drm/i915: Improve lockdep tracking for obj->mm.lock

On ti, 2016-11-01 at 12:11 +, Chris Wilson wrote: > The shrinker may appear to recurse into obj->mm.lock as the shrinker may > be called from a direct reclaim path whilst handling get_pages. We > filter out recursing on the same obj->mm.lock by inspecting > obj->mm.pages, but we do want to

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

== Series Details == Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence URL : https://patchwork.freedesktop.org/series/14669/ State : warning == Summary == Series 14669v1 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

[Intel-gfx] [PATCH] drm/i915: Improve lockdep tracking for obj->mm.lock

The shrinker may appear to recurse into obj->mm.lock as the shrinker may be called from a direct reclaim path whilst handling get_pages. We filter out recursing on the same obj->mm.lock by inspecting obj->mm.pages, but we do want to take the lock on a second object in order to reap their pages.

[Intel-gfx] [CI] drm/i915: Store the vma in an rbtree under the object

With full-ppgtt one of the main bottlenecks is the lookup of the VMA underneath the object. For execbuf there is merit in having a very fast direct lookup of ctx:handle to the vma using a hashtree, but that still leaves a large number of other lookups. One way to speed up the lookup would be to

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

On ti, 2016-11-01 at 13:11 +0200, Ander Conselvan de Oliveira wrote: > Hardware engineers confirmed that writing to it has no effect, as implied by > the FIXME comment. > > Cc: Imre Deak > Signed-off-by: Ander Conselvan de Oliveira >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

On Mon, Oct 31, 2016 at 09:16:10PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: A game of OCD dominoes > URL : https://patchwork.freedesktop.org/series/14634/ > State : warning > > == Summary == > > Series 14634v1 drm/i915: A game of OCD dominoes >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

On Tue, Nov 01, 2016 at 10:46:07AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Avoid accessing > request->timeline outside of its lifetime > URL : https://patchwork.freedesktop.org/series/14665/ > State : warning > > == Summary == > >

[Intel-gfx] [PATCH igt 2/2] igt/kms_flip: Use the computed vblank interval for TS checking

Since the modeline may differ from actual hardware timings, do not rely upon it but instead measure the actual and verify that it does not change across the various flip/vblank configurations. Signed-off-by: Chris Wilson --- tests/kms_flip.c | 33

[Intel-gfx] [PATCH igt 1/2] igt/kms_flip: Mark frame_time() as coming from the mode

Signed-off-by: Chris Wilson --- tests/kms_flip.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 9829b35..74754d1 100644 --- a/tests/kms_flip.c +++ b/tests/kms_flip.c @@ -574,7

[Intel-gfx] [PATCH v2.1 03/11] drm/i915/gen9+: Use for_each_intel_plane_on_crtc in skl_print_wm_changes, v2.

Using for_each_intel_plane_on_crtc will allow us to find all allocations that may have changed, not just the one added by the atomic state. This will print changes to plane allocations for crtc's when some planes are not added to the atomic state. Changes since v1: - Rephrase commit message.

[Intel-gfx] [PATCH] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

Hardware engineers confirmed that writing to it has no effect, as implied by the FIXME comment. Cc: Imre Deak Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_dpio_phy.c | 16 1 file changed,

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

== Series Details == Series: series starting with [CI,1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime URL : https://patchwork.freedesktop.org/series/14665/ State : warning == Summary == Series 14665v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

On Tue, Nov 01, 2016 at 12:22:45PM +0200, Mika Kuoppala wrote: > Joonas Lahtinen writes: > >> @@ -735,8 +737,8 @@ static bool gen8_ppgtt_clear_pt(struct > >> i915_address_space *vm, > >>   > >>   pt_vaddr = kmap_px(pt); > >>   > >> - for (pte = pte_start; pte <

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

Joonas Lahtinen writes: > On ma, 2016-10-31 at 17:55 +0200, Mika Kuoppala wrote: >> @@ -712,13 +712,13 @@ static int gen8_48b_mm_switch(struct i915_hw_ppgtt >> *ppgtt, >>   */ >>  static bool gen8_ppgtt_clear_pt(struct i915_address_space *vm, >>  

[Intel-gfx] [CI 1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking locks within request deallocation, we drop references to its timeline (via the context and ppgtt) upon retirement. We should avoid chasing such pointers

[Intel-gfx] [CI 2/2] drm/i915: Track pages pinned due to swizzling quirk

If we have a tiled object and an unknown CPU swizzle pattern, we pin the pages to prevent the object from being swapped out (and us corrupting the contents as we do not know the access pattern and so cannot convert it to linear and back to tiled on reuse). This requires us to remember to drop the

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On Tue, Nov 01, 2016 at 09:43:53AM +, Tvrtko Ursulin wrote: > > On 31/10/2016 10:26, Chris Wilson wrote: > >With full-ppgtt one of the main bottlenecks is the lookup of the VMA > >underneath the object. For execbuf there is merit in having a very fast > >direct lookup of ctx:handle to the vma

Re: [Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

On Mon, Oct 31, 2016 at 08:56:34PM +, Chris Wilson wrote: > On Mon, Oct 31, 2016 at 10:36:59PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I pretty much just wanted to store struct intel_crtc * instead > > of struct drm_crtc * in

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On Tue, Nov 01, 2016 at 09:20:33AM +, Tvrtko Ursulin wrote: > > On 01/11/2016 09:06, Chris Wilson wrote: > >On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote: > >> > >>On 01/11/2016 08:50, Chris Wilson wrote: > >>>On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On 31/10/2016 10:26, Chris Wilson wrote: With full-ppgtt one of the main bottlenecks is the lookup of the VMA underneath the object. For execbuf there is merit in having a very fast direct lookup of ctx:handle to the vma using a hashtree, but that still leaves a large number of other lookups.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

On Tue, Nov 01, 2016 at 09:20:19AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/3] drm/i915: Use the full hammer when > shutting down the rcu tasks > URL : https://patchwork.freedesktop.org/series/14660/ > State : warning > > == Summary == > > Series

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On 01/11/2016 09:06, Chris Wilson wrote: On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote: On 01/11/2016 08:50, Chris Wilson wrote: On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote: On 31/10/2016 10:26, Chris Wilson wrote: With full-ppgtt one of the main

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

== Series Details == Series: series starting with [CI,1/3] drm/i915: Use the full hammer when shutting down the rcu tasks URL : https://patchwork.freedesktop.org/series/14660/ State : warning == Summary == Series 14660v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

On ti, 2016-11-01 at 09:15 +, Chris Wilson wrote: > On Tue, Nov 01, 2016 at 11:10:31AM +0200, Joonas Lahtinen wrote: > > > > On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote: > > As discussed in IRC, I think we rather should add a lock class to > > obj->mm, to avoid chasing these in the

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

On Tue, Nov 01, 2016 at 11:10:31AM +0200, Joonas Lahtinen wrote: > On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote: > As discussed in IRC, I think we rather should add a lock class to > obj->mm, to avoid chasing these in the future. All ears :) The complicated one isn't obj->mm, but the

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote: > As we may allocate from within the obj->mm.lock we may enter the > shrinker for direct reclaim. Operating on the current object is > prevented by checking for obj->mm.pages (which is only set as the last > operation in the allocation path).

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

On Tue, 2016-11-01 at 09:57 +0100, Maarten Lankhorst wrote: > Otherwise looks sane, I have a similar patch in my tree. I didn't > submit it yet but the fix was similar. Except for the > dev_cdclk stuff. > > With the last dev_cdclk assignment removed: > > Reviewed-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote: > > On 01/11/2016 08:50, Chris Wilson wrote: > >On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote: > >> > >>On 31/10/2016 10:26, Chris Wilson wrote: > >>>With full-ppgtt one of the main bottlenecks is the lookup of the

Re: [Intel-gfx] [PATCH i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

On Tue, 2016-11-01 at 09:25 +0100, Maarten Lankhorst wrote: > Op 20-10-16 om 11:27 schreef Mika Kahola: > > > > This is a testcase with multiple planes. The idea here is the > > following > > > >  - draw a uniform frame with blue color > >  - grab crc for reference > >  - put planes randomly on

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > When we end up not recomputing the cdclk, we need to populate > intel_state->cdclk with the "atomic_cdclk_freq" instead of the > current cdclk_freq. When no pipes are active, the

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On 01/11/2016 08:50, Chris Wilson wrote: On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote: On 31/10/2016 10:26, Chris Wilson wrote: With full-ppgtt one of the main bottlenecks is the lookup of the VMA underneath the object. For execbuf there is merit in having a very fast

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Track pages pinned due to swizzling quirk

On 01/11/2016 08:48, Chris Wilson wrote: On Tue, Nov 01, 2016 at 08:39:14AM +, Tvrtko Ursulin wrote: On 31/10/2016 10:26, Chris Wilson wrote: If we have a tiled object and an unknown CPU swizzle pattern, we pin the pages to prevent the object from being swapped out (and us corrupting the

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

On Sat, 29 Oct 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 retry. We save the link rate > value at which link training failed, update

[Intel-gfx] [CI 3/3] drm/i915: Move the recently scanned objects to the tail after shrinking

During shrinking, we walk over the list of objects searching for victims. Any that are not removed are put back into the global list. Currently, they are put back in order (at the front) which means they will be first to be scanned again. If we instead move them to the rear of the list, we will

[Intel-gfx] [CI 2/3] drm/i915: Discard objects from mm global_list after being shrunk

In the shrinker, we can safely remove an empty object (obj->mm.pages == NULL) after having discarded the pages because we are holding the struct_mutex. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [CI 1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

To flush all call_rcu() tasks (here from i915_gem_free_object()) we need to call rcu_barrier() (not synchronize_rcu()). If we don't then we may still have objects being freed as we continue to teardown the driver - in particular, the recently released rings may race with the memory manager

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Track pages pinned due to swizzling quirk

On Tue, Nov 01, 2016 at 08:39:14AM +, Tvrtko Ursulin wrote: > > On 31/10/2016 10:26, Chris Wilson wrote: > >If we have a tiled object and an unknown CPU swizzle pattern, we pin the > >pages to prevent the object from being swapped out (and us corrupting > >the contents as we do not know the

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Avoid accessing request->timeline outside of its lifetime

On 31/10/2016 21:03, Chris Wilson wrote: On Mon, Oct 31, 2016 at 05:35:50PM +, Tvrtko Ursulin wrote: On 31/10/2016 10:26, Chris Wilson wrote: Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

On 31/10/2016 10:26, Chris Wilson wrote: With full-ppgtt one of the main bottlenecks is the lookup of the VMA underneath the object. For execbuf there is merit in having a very fast direct lookup of ctx:handle to the vma using a hashtree, but that still leaves a large number of other lookups.

  1   2   >