Re: [Intel-gfx] [PATCH 4/6] drm/i915: Discard objects from mm global_list after being shrunk

On 31/10/2016 10:26, Chris Wilson wrote: 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 --- drivers/gpu/drm/i915/i915_gem_shrinker.c

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] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Op 20-10-16 om 23:57 schreef Matt Roper: > On Wed, Oct 12, 2016 at 03:28:20PM +0200, Maarten Lankhorst wrote: >> Instead of running the watermark updates from the callbacks run >> them from a separate hook atomic_evade_watermarks. > The commit message here is a bit terse. I'd clarify that the

Re: [Intel-gfx] [i-g-t PATCH v2] tests: do snd_hda_intel unbind before unload in module reload test

On Tue, 01 Nov 2016, "Yang, Libin" wrote: > Reviewed-by: Libin Yang Pushed both patches to igt, thanks for the review. BR, Jani. > > Regards, > Libin > > >> -Original Message- >> From: Nikula, Jani >> Sent: Monday, October 31, 2016 7:00 PM

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 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

[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 ---

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 1/2] drm/i915/gtt: Fix pte clear range

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, >   struct i915_page_table *pt, > -

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 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] 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] 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] ✗ 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 i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

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 top with the same blue color > - punch holes with black color into the primary

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

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 access pattern and so cannot convert it to linear and back to tiled on

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 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

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, a batch of i915 fixes for v4.9. BR, Jani. The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69: Linux 4.9-rc2 (2016-10-23 17:10:14 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-11-01 for

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] 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] 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

[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 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, >>  

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 <

[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] 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 >

[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

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] [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] [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] [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 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: 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] 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 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 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: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 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.

[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,

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] 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.

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

[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 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

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

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

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] [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ä

[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: 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 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

[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 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] 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] [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: >

[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

[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] 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: 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 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 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 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] ✗ 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] [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] [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] [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] [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

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] ✗ 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

[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] [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

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 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

[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

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 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] 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 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

[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

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

[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

[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

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

[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/

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,

  1   2   >