[Intel-gfx] [PATCH] drm/i915/selftests: Prevent background reaping of active objects

igt_mmap_offset_exhaustion() wants to test what happens when the mmap space is filled with zombie objects, objects discarded by userspace but still active on the GPU. As they are only protected by the active reference, we have to be certain that active reference is kept while we peek into our dangl

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Prevent background reaping of active objects (rev2)

== Series Details == Series: drm/i915/selftests: Prevent background reaping of active objects (rev2) URL : https://patchwork.freedesktop.org/series/46124/ State : warning == Summary == $ dim checkpatch origin/drm-tip de95eb144288 drm/i915/selftests: Prevent background reaping of active objects

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Prevent background reaping of active objects (rev2)

== Series Details == Series: drm/i915/selftests: Prevent background reaping of active objects (rev2) URL : https://patchwork.freedesktop.org/series/46124/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4451 -> Patchwork_9585 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] [PATCH 02/12] blk: use for_each_if

Makes the macros resilient against if {} else {} blocks right afterwards. Signed-off-by: Daniel Vetter Cc: Tejun Heo Cc: Jens Axboe Cc: Shaohua Li Cc: Kate Stewart Cc: Greg Kroah-Hartman Cc: Joseph Qi Cc: Daniel Vetter Cc: Arnd Bergmann --- include/linux/blk-cgroup.h | 4 ++-- 1 file cha

[Intel-gfx] [PATCH 03/12] cgroup: use for_each_if

Avoids the need to invert the condition instead of the open-coded version. Signed-off-by: Daniel Vetter Cc: Tejun Heo Cc: Li Zefan Cc: Johannes Weiner Cc: cgro...@vger.kernel.org --- include/linux/cgroup.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/cg

[Intel-gfx] [PATCH 06/12] mm: use for_each_if

Avoids the inverted condition of the open-coded version. Signed-off-by: Daniel Vetter Cc: Andrew Morton Cc: Michal Hocko Cc: Vlastimil Babka Cc: Mel Gorman Cc: David Rientjes Cc: Kemi Wang Cc: Pavel Tatashin Cc: Petr Tesarik Cc: YASUAKI ISHIMATSU Cc: Andrey Ryabinin Cc: Nikolay Borisov

[Intel-gfx] [PATCH 08/12] netdev: use for_each_if

Avoids complaints from gcc about ambiguous else clauses. Signed-off-by: Daniel Vetter Cc: "David S. Miller" Cc: net...@vger.kernel.org --- include/linux/netdevice.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 3e

[Intel-gfx] [PATCH 10/12] pci: use for_each_if

Avoids the inverted condition compared to the open-coded version. Signed-off-by: Daniel Vetter Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org --- include/linux/pci.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/pci.h b/include/linux/pci.h index 340029b2fb38

[Intel-gfx] [PATCH 01/12] kernel.h: Add for_each_if()

To avoid compilers complainig about ambigious else blocks when putting an if condition into a for_each macro one needs to invert the condition and add a dummy else. We have a nice little convenience macro for that in drm headers, let's move it out. Subsequent patches will roll it out to other place

[Intel-gfx] [PATCH 05/12] dmar: Use for_each_If

Avoids the inverted conditions compared to the open coded version. Signed-off-by: Daniel Vetter Cc: Joerg Roedel --- include/linux/dmar.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/include/linux/dmar.h b/include/linux/dmar.h index e2433bc50210..99397504e75e 100

[Intel-gfx] [PATCH 09/12] nubus: use for_each_if

Avoids the inverted check compared to the open-coded version. Signed-off-by: Daniel Vetter Cc: Finn Thain Cc: linux-m...@lists.linux-m68k.org --- include/linux/nubus.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/nubus.h b/include/linux/nubus.h index eba50b0

[Intel-gfx] [PATCH 04/12] cpufreq: use for_each_if

Avoids the inverted condition compared to the open coded version. Signed-off-by: Daniel Vetter Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linux...@vger.kernel.org --- include/linux/cpufreq.h | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/linux/cpufreq.h b

[Intel-gfx] [PATCH 07/12] ide: use for_each_if

Avoids complaints from gcc about ambigious else clauses. Not that any of those are likely to show up in ide ... Signed-off-by: Daniel Vetter Cc: "David S. Miller" Cc: linux-...@vger.kernel.org --- include/linux/ide.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/li

[Intel-gfx] [PATCH 12/12] usb: use for_each_if

Avoids the inverted condition compared to the open-coded version. Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org --- include/linux/usb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/usb.h b/include/linux/usb.h index 4cdd515

[Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

Avoids complaints from gcc about ambiguous else clauses. Signed-off-by: Daniel Vetter Cc: Andrew Morton Cc: Peter Zijlstra --- include/linux/topology.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/topology.h b/include/linux/topology.h index cb0775e1ee4b..4f

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/12] kernel.h: Add for_each_if()

== Series Details == Series: series starting with [01/12] kernel.h: Add for_each_if() URL : https://patchwork.freedesktop.org/series/46158/ State : warning == Summary == $ dim checkpatch origin/drm-tip c4210eba974e kernel.h: Add for_each_if() -:6: WARNING:TYPO_SPELLING: 'ambigious' may be miss

[Intel-gfx] [PATCH] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Usually we have no idea about the upper bound we need to wait to catch up with userspace when idling the device, but in a few situations we know the system was idle beforehand and can provide a short timeout in order to very quickly catch a failure, long before hangcheck kicks in. In particular, w

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/12] kernel.h: Add for_each_if()

== Series Details == Series: series starting with [01/12] kernel.h: Add for_each_if() URL : https://patchwork.freedesktop.org/series/46158/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4451 -> Patchwork_9586 = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Provide a timeout to i915_gem_wait_for_idle()

== Series Details == Series: drm/i915: Provide a timeout to i915_gem_wait_for_idle() URL : https://patchwork.freedesktop.org/series/46161/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4451 -> Patchwork_9587 = == Summary - SUCCESS == No regressions found. External URL

Re: [Intel-gfx] [PATCH 04/12] cpufreq: use for_each_if

On Monday, 2018-07-09 10:36:42 +0200, Daniel Vetter wrote: > Avoids the inverted condition compared to the open coded version. > > Signed-off-by: Daniel Vetter > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > --- > include/linux/cpufreq.h | 8 ++-- > 1 file cha

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Prevent background reaping of active objects (rev2)

== Series Details == Series: drm/i915/selftests: Prevent background reaping of active objects (rev2) URL : https://patchwork.freedesktop.org/series/46124/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4451_full -> Patchwork_9585_full = == Summary - WARNING == Minor unkno

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Magic numbers for old Y-tiling

Chris Wilson writes: > i915g has a slightly different tiling layout, and so requires a > different reference swizzle pattern. > > Testcase: igt/drv_selftests/live_objects #gdg > Signed-off-by: Chris Wilson Acked-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/selftests/i915_gem_object.c | 11

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Magic numbers for old Y-tiling

Quoting Mika Kuoppala (2018-07-09 10:57:19) > Chris Wilson writes: > > > i915g has a slightly different tiling layout, and so requires a > > different reference swizzle pattern. > > > > Testcase: igt/drv_selftests/live_objects #gdg > > Signed-off-by: Chris Wilson > > Acked-by: Mika Kuoppala T

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Provide a timeout to i915_gem_wait_for_idle()

== Series Details == Series: drm/i915: Provide a timeout to i915_gem_wait_for_idle() URL : https://patchwork.freedesktop.org/series/46161/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4451_full -> Patchwork_9587_full = == Summary - WARNING == Minor unknown changes comin

[Intel-gfx] [PATCH v4] drm/i915/gvt: declare gvt as i915's soft dependency

From: Hang Yuan This helps initramfs builder and other tools to know the full dependencies of i915 and have gvt module loaded with i915. v2: add condition and change to pre-dependency (Chris) v3: move declaration to gvt.c. (Chris) v4: remove xengt (Zhenyu) Signed-off-by: Hang Yuan Reviewed-by:

[Intel-gfx] [PATCH i-g-t] igt/gem_render_copy: Check for GEM before running

gem_render_copy requires a working GPU so check first. Signed-off-by: Chris Wilson --- tests/gem_render_copy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c index 8373cd738..238e70e97 100644 --- a/tests/gem_render_copy.c +++ b/tests/gem_ren

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: > Avoids complaints from gcc about ambiguous else clauses. Is that a new thing? I'm fairly sure I've never seen it do that, > Signed-off-by: Daniel Vetter > Cc: Andrew Morton > Cc: Peter Zijlstra > --- > include/linux/topology.h |

[Intel-gfx] [PATCH 2/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup

With a broken GPU we expect it to fail during the initial GPU setup where do a couple of context switches to record the defaults. This is a task that takes a few milliseconds even on the slowest of devices, but we may have to wait 60s for hangcheck to give in and declare the machine inoperable. In

[Intel-gfx] [PATCH 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Usually we have no idea about the upper bound we need to wait to catch up with userspace when idling the device, but in a few situations we know the system was idle beforehand and can provide a short timeout in order to very quickly catch a failure, long before hangcheck kicks in. In the following

[Intel-gfx] [PATCH 3/3] drm/i915/selftests: Replace wait-on-timeout with explicit timeout

In igt_flush_test() we install a background timer in order to ensure that the wait completes within a certain time. We can now tell the wait that it has to complete within a timeout, and so no longer need the background timer. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Mika Kuoppala Cc

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: declare gvt as i915's soft dependency (rev2)

== Series Details == Series: drm/i915/gvt: declare gvt as i915's soft dependency (rev2) URL : https://patchwork.freedesktop.org/series/45875/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4453 -> Patchwork_9588 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

== Series Details == Series: series starting with [1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() URL : https://patchwork.freedesktop.org/series/46170/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4453 -> Patchwork_9589 = == Summary - SUCCESS == No regres

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Chris Wilson writes: > Usually we have no idea about the upper bound we need to wait to catch > up with userspace when idling the device, but in a few situations we > know the system was idle beforehand and can provide a short timeout in > order to very quickly catch a failure, long before hangch

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Quoting Mika Kuoppala (2018-07-09 12:38:10) > Chris Wilson writes: > > -int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int > > flags) > > +int i915_gem_wait_for_idle(struct drm_i915_private *i915, > > +unsigned int flags, long timeout) > > { > >

Re: [Intel-gfx] [PATCH 01/12] kernel.h: Add for_each_if()

On Mon, 2018-07-09 at 10:36 +0200, Daniel Vetter wrote: > To avoid compilers complainig about ambigious else blocks when putting > an if condition into a for_each macro one needs to invert the > condition and add a dummy else. We have a nice little convenience > macro for that in drm headers, let's

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Chris Wilson writes: > Quoting Mika Kuoppala (2018-07-09 12:38:10) >> Chris Wilson writes: >> > -int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int >> > flags) >> > +int i915_gem_wait_for_idle(struct drm_i915_private *i915, >> > +unsigned int flags, l

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup

Chris Wilson writes: > With a broken GPU we expect it to fail during the initial > GPU setup where do a couple of context switches to record the defaults. > This is a task that takes a few milliseconds even on the slowest of > devices, but we may have to wait 60s for hangcheck to give in and > de

Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: Replace wait-on-timeout with explicit timeout

Chris Wilson writes: > In igt_flush_test() we install a background timer in order to ensure > that the wait completes within a certain time. We can now tell the wait > that it has to complete within a timeout, and so no longer need the > background timer. > > Signed-off-by: Chris Wilson > Cc: Jo

[Intel-gfx] [CI 2/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup

With a broken GPU we expect it to fail during the initial GPU setup where do a couple of context switches to record the defaults. This is a task that takes a few milliseconds even on the slowest of devices, but we may have to wait 60s for hangcheck to give in and declare the machine inoperable. In

[Intel-gfx] [CI 3/3] drm/i915/selftests: Replace wait-on-timeout with explicit timeout

In igt_flush_test() we install a background timer in order to ensure that the wait completes within a certain time. We can now tell the wait that it has to complete within a timeout, and so no longer need the background timer. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Mika Kuoppala Cc

[Intel-gfx] [CI 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Usually we have no idea about the upper bound we need to wait to catch up with userspace when idling the device, but in a few situations we know the system was idle beforehand and can provide a short timeout in order to very quickly catch a failure, long before hangcheck kicks in. In the following

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Wed 27-06-18 09:44:21, Michal Hocko wrote: > This is the v2 of RFC based on the feedback I've received so far. The > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > because I have no idea how. > > Any further feedback is highly appreciated of course. Any other feedba

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

== Series Details == Series: series starting with [CI,1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() URL : https://patchwork.freedesktop.org/series/46175/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4453 -> Patchwork_9590 = == Summary - SUCCESS == No reg

[Intel-gfx] [PATCH 08/11] drm/i915: Move fence-reg interface to i915_gem_fence_reg.h

Since we have a header file for i915_gem_fence_reg, let's use it for the interface prototypes currently hidden away in the huge i915_drv.h Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 15 --- drivers/gpu/drm/i915/i915_gem_fence_reg.h | 16 ++

[Intel-gfx] [PATCH 02/11] drm/i915: Only reset hangcheck at the start of an activity cycle

Across a reset, the seqno (and thus hangcheck) should restart and the hangcheck naturally progress, for when it does not, we want to declare an emergency. Currently, we only detect if reset and reinit fails, but we do not detect if the call to reinit succeeds but the HW is fried - as we are resetti

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: declare gvt as i915's soft dependency (rev2)

== Series Details == Series: drm/i915/gvt: declare gvt as i915's soft dependency (rev2) URL : https://patchwork.freedesktop.org/series/45875/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4453_full -> Patchwork_9588_full = == Summary - WARNING == Minor unknown changes co

[Intel-gfx] [PATCH 07/11] drm/i915: Tidy i915_gem_suspend()

In the next patch, we will make a fairly minor change to flush outstanding resets before suspend. In order to keep churn to a minimum in that functional patch, we fix up the comments and coding style now. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 50 +-

[Intel-gfx] [PATCH 11/11] drm/i915: Remove GPU reset dependence on struct_mutex

Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend ind

[Intel-gfx] [PATCH 03/11] drm/i915: Stop tracking MRU activity on VMA

Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracki

[Intel-gfx] [PATCH 05/11] drm/i915: Move fence register tracking to GGTT

As the fence registers define special regions of the mappable aperture inside the Global GTT, and we track those regions using GGTT VMA, it makes sense to pull that bookkeeping under i915_ggtt. The advantage is that we can then start using a local GGTT lock to handle the fence registers (in conjunc

[Intel-gfx] [PATCH 06/11] drm/i915: Convert fences to use a GGTT lock rather than struct_mutex

Introduce a new mutex to guard all of the vma operations within a vm (as opposed to the BKL struct_mutex) and start by using it to guard the fence operations for a GGTT VMA. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 9 ++- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 04/11] drm/i915: Introduce i915_address_space.mutex

Add a mutex into struct i915_address_space to be used while operating on the vma and their lists for a particular vm. As this may be called from the shrinker, we taint the mutex with fs_reclaim so that from the start lockdep warns us if we are caught holding the mutex across an allocation. (With su

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

Quoting Mika Kuoppala (2018-07-09 12:52:51) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2018-07-09 12:38:10) > >> Chris Wilson writes: > >> > -int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int > >> > flags) > >> > +int i915_gem_wait_for_idle(struct drm_i915_private

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_render_copy: Check for GEM before running

On Mon, Jul 09, 2018 at 11:28:47AM +0100, Chris Wilson wrote: > gem_render_copy requires a working GPU so check first. > > Signed-off-by: Chris Wilson > --- > tests/gem_render_copy.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c > ind

[Intel-gfx] [PATCH 01/11] drm/i915/selftests: Prevent background reaping of active objects

igt_mmap_offset_exhaustion() wants to test what happens when the mmap space is filled with zombie objects, objects discarded by userspace but still active on the GPU. As they are only protected by the active reference, we have to be certain that active reference is kept while we peek into our dangl

[Intel-gfx] [PATCH 10/11] drm/i915: Pull all the reset functionality together into i915_reset.c

Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile |3 +- drivers/gpu/drm/i915/i915_debugfs.c |2 + drivers/gpu/drm/i915

[Intel-gfx] [PATCH i-g-t 03/11] trace.pl: Scale timeline for better precision

From: Tvrtko Ursulin vis library has a limited precision compared to our trace data which prevents zooming into the timeline and seeing the fine detail. Scale the HTML view by a thousand to work around it. Signed-off-by: Tvrtko Ursulin Suggested-by: John Harrison Cc: John Harrison --- scrip

[Intel-gfx] [PATCH i-g-t 04/11] trace.pl: Put single context at single vertical slot

From: Tvrtko Ursulin Turn off timeline stacking in favour of putting all the boxes belonging to a single context at the same vertical slot. Also remove the custom sorting function in favour of correctly assigning the subgroup id's and order which greatly speeds up the library operations. And fi

[Intel-gfx] [PATCH i-g-t 07/11] trace.pl: Fix engine busy accounting in split mode

From: Tvrtko Ursulin In split mode all requests have to be added up since they were previously re-arranged so there is no overlap. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/trace.pl b/scri

[Intel-gfx] [PATCH 09/11] drm/i915: Dynamically allocate the array of drm_i915_gem_fence_reg

If we dynamically allocate the correct sized array for the fence registers, we can avoid the 4x overallocation on older, typically smaller devices and avoid having to know the static layout in advance. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 33 d

[Intel-gfx] [PATCH i-g-t 01/11] trace.pl: Fix no context colouring mode

From: Tvrtko Ursulin Commit 87d2affc380da96ba66c258c5337c363fe8651ef ("trace.pl: Add support for colouring context execution"), due some dodgy attempts at patch splitting broke the legacy colouring mode. Fix it by passing in the request stage into the helper so all stages can be correctly colour

[Intel-gfx] [PATCH i-g-t 00/11] trace.pl fixes and improvements

From: Tvrtko Ursulin Latest state of patches preceding the virtual engine support. Tvrtko Ursulin (11): trace.pl: Fix no context colouring mode trace.pl: Improve readability of graphical timeline representation trace.pl: Scale timeline for better precision trace.pl: Put single context at

[Intel-gfx] [PATCH i-g-t 09/11] trace.pl: Fix incomplete request handling

From: Tvrtko Ursulin Incomplete requests (no notify, no context complete) have to be corrected by looking at the engine timeline, and not the sorted-by-start-time view as was previously used. Per-engine timelines are generated on demand and cached for later use. v2: Find end of current context

[Intel-gfx] [PATCH i-g-t 02/11] trace.pl: Improve readability of graphical timeline representation

From: Tvrtko Ursulin We add stripes for different stages of request execution so it is easier to follow one context in the multi-colour mode. Vertical stripe pattern indicates pipeline "blockages" - requests waiting for dependencies before they are runnable. Diagonal stripes indicate runnable r

[Intel-gfx] [PATCH i-g-t 05/11] trace.pl: Fix HTML timestamp generation

From: Tvrtko Ursulin Now that we scale timestamps to get better timeline granularity, the hacky hand rolled micro-second time to HTML date conversion does no longer cut it. Use perl built-in gmtime to handle things properly. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.p

[Intel-gfx] [PATCH i-g-t 08/11] trace.pl: Context save only applies to last request of a bunch

From: Tvrtko Ursulin Skip accounting the context save time for anything but the last request of the coalesced bunch, and also skip drawing those boxes on the timeline. Signed-off-by: Tvrtko Ursulin --- scripts/trace.pl | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --gi

[Intel-gfx] [PATCH i-g-t 06/11] trace.pl: Improve context colouring for large context id's

From: Tvrtko Ursulin John reports that on a long runnning systems the huge disparity between kernel context and user context id's causes all interesting colours to be clustered too close together. Fix this by assigning colours to seen contexts instead of basing purely on context id's. Signed-of

[Intel-gfx] [PATCH i-g-t 10/11] trace.pl: Basic preemption support

From: Tvrtko Ursulin Just forget about earlier request_in events. Signed-off-by: Tvrtko Ursulin --- scripts/trace.pl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index 6379dace5743..5da5f5a14104 100755 --- a/scripts/trace.pl +++ b/s

[Intel-gfx] [PATCH i-g-t 11/11] trace.pl: Fix request split mode

From: Tvrtko Ursulin Request split mode had several bugs, both in the original version and also after the recent refactorings. One big one was that it wasn't considering different submit ports as a reason to split execution, and also that it was too time based instead of looking at relevant time

[Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.

The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prior requests are executed on old coherency settings, and all exec requests after the IOCTL

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_render_copy: Check for GEM before running

Quoting Ville Syrjälä (2018-07-09 14:19:40) > On Mon, Jul 09, 2018 at 11:28:47AM +0100, Chris Wilson wrote: > > gem_render_copy requires a working GPU so check first. > > > > Signed-off-by: Chris Wilson > > --- > > tests/gem_render_copy.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff -

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 03/11] trace.pl: Scale timeline for better precision

Quoting Tvrtko Ursulin (2018-07-09 14:19:56) > From: Tvrtko Ursulin > > vis library has a limited precision compared to our trace data which > prevents zooming into the timeline and seeing the fine detail. > > Scale the HTML view by a thousand to work around it. Shouldn't there be some clue in

[Intel-gfx] [RFC COMP I/F] drm/i915: Initialize HDCP2.2 and its MEI interface

Initialize HDCP2.2 support. This includes the mei interface initialization along with required component registration. v2: mei interface handle is protected with mutex. [Chris Wilson] v3: Notifiers are used for the mei interface state. v4: Poll for mei client device state Error msg for out

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects

== Series Details == Series: series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects URL : https://patchwork.freedesktop.org/series/46176/ State : warning == Summary == $ dim checkpatch origin/drm-tip d53e6a02a19e drm/i915/selftests: Prevent background re

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 03/11] trace.pl: Scale timeline for better precision

On 09/07/2018 14:26, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-07-09 14:19:56) From: Tvrtko Ursulin vis library has a limited precision compared to our trace data which prevents zooming into the timeline and seeing the fine detail. Scale the HTML view by a thousand to work around it.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects

== Series Details == Series: series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects URL : https://patchwork.freedesktop.org/series/46176/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/selftests: Prevent background reaping of

Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.

On 09/07/18 14:20, Tomasz Lis wrote: The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prior requests are executed on old coherency settings,

Re: [Intel-gfx] [PATCH 01/11] drm/i915/selftests: Prevent background reaping of active objects

Chris Wilson writes: > igt_mmap_offset_exhaustion() wants to test what happens when the mmap > space is filled with zombie objects, objects discarded by userspace but > still active on the GPU. As they are only protected by the active > reference, we have to be certain that active reference is ke

[Intel-gfx] [PATCH] drm/i915: Remove function details from device error messages

Error messages are intended to be addressed to the user; be clear, succinct, instructive and unambiguous. Adding the function name to that message does not add any information the user requires and in the process makes the message less clear. E.g. [ 245.539711] i915 :00:02.0: [drm:i915_gem_i

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects

== Series Details == Series: series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects URL : https://patchwork.freedesktop.org/series/46176/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9591 = == Summary - SUCCESS ==

Re: [Intel-gfx] [PATCH 01/11] drm/i915/selftests: Prevent background reaping of active objects

Quoting Mika Kuoppala (2018-07-09 14:48:31) > Chris Wilson writes: > > > igt_mmap_offset_exhaustion() wants to test what happens when the mmap > > space is filled with zombie objects, objects discarded by userspace but > > still active on the GPU. As they are only protected by the active > > refe

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle()

== Series Details == Series: series starting with [1/3] drm/i915: Provide a timeout to i915_gem_wait_for_idle() URL : https://patchwork.freedesktop.org/series/46170/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4453_full -> Patchwork_9589_full = == Summary - WARNING ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency. (rev5)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev5) URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim checkpatch origin/drm-tip c705f01c81f1 drm/i915: Add IOCTL Param to control data port coherency. -:15: WARNING:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add Exec param to control data port coherency. (rev5)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev5) URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Add IOCTL Param to control data port coherency. -drivers/gpu/drm/i915/s

Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.

On 2018-07-09 15:48, Lionel Landwerlin wrote: On 09/07/18 14:20, Tomasz Lis wrote: The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prio

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Initialize HDCP2.2 and its MEI interface

== Series Details == Series: drm/i915: Initialize HDCP2.2 and its MEI interface URL : https://patchwork.freedesktop.org/series/46180/ State : failure == Summary == Applying: drm/i915: Initialize HDCP2.2 and its MEI interface error: sha1 information is lacking or useless (drivers/gpu/drm/i915/

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Only reset hangcheck at the start of an activity cycle

Chris Wilson writes: > Across a reset, the seqno (and thus hangcheck) should restart and the > hangcheck naturally progress, for when it does not, we want to declare an > emergency. Currently, we only detect if reset and reinit fails, but we > do not detect if the call to reinit succeeds but the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Exec param to control data port coherency. (rev5)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev5) URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9592 = == Summary - SUCCESS == No regressions found. Exte

Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.

On 09/07/18 15:03, Lis, Tomasz wrote: On 2018-07-09 15:48, Lionel Landwerlin wrote: On 09/07/18 14:20, Tomasz Lis wrote: The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Only reset hangcheck at the start of an activity cycle

Quoting Mika Kuoppala (2018-07-09 15:13:44) > Chris Wilson writes: > > > Across a reset, the seqno (and thus hangcheck) should restart and the > > hangcheck naturally progress, for when it does not, we want to declare an > > emergency. Currently, we only detect if reset and reinit fails, but we >

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Only reset hangcheck at the start of an activity cycle

Chris Wilson writes: > Quoting Mika Kuoppala (2018-07-09 15:13:44) >> Chris Wilson writes: >> >> > Across a reset, the seqno (and thus hangcheck) should restart and the >> > hangcheck naturally progress, for when it does not, we want to declare an >> > emergency. Currently, we only detect if re

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove function details from device error messages

== Series Details == Series: drm/i915: Remove function details from device error messages URL : https://patchwork.freedesktop.org/series/46187/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9594 = == Summary - SUCCESS == No regressions found. Externa

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote: > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: >> Avoids complaints from gcc about ambiguous else clauses. > > Is that a new thing? I'm fairly sure I've never seen it do that, > >> Signed-off-by: Daniel Vetter >> Cc: Andrew

Re: [Intel-gfx] [RFC COMP I/F] drm/i915: Initialize HDCP2.2 and its MEI interface

On Mon, Jul 09, 2018 at 07:01:09PM +0530, Ramalingam C wrote: > Initialize HDCP2.2 support. This includes the mei interface > initialization along with required component registration. > > v2: > mei interface handle is protected with mutex. [Chris Wilson] > v3: > Notifiers are used for the mei

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote: > On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote: > > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: > >> #define for_each_node_with_cpus(node)\ > >> for_each_online_node(node)

Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.

On 2018-07-09 16:24, Lionel Landwerlin wrote: On 09/07/18 15:03, Lis, Tomasz wrote: On 2018-07-09 15:48, Lionel Landwerlin wrote: On 09/07/18 14:20, Tomasz Lis wrote: The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is calle

Re: [Intel-gfx] [RFC COMP I/F] drm/i915: Initialize HDCP2.2 and its MEI interface

On Monday 09 July 2018 08:40 PM, Daniel Vetter wrote: On Mon, Jul 09, 2018 at 07:01:09PM +0530, Ramalingam C wrote: Initialize HDCP2.2 support. This includes the mei interface initialization along with required component registration. v2: mei interface handle is protected with mutex. [Chri

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:12:58PM +0200, Peter Zijlstra wrote: > On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote: > > On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra > > wrote: > > > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote: > > > >> #define for_each_node_wit

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote: > for_each_something(foo) > if (foo->bla) > call_bla(foo); > else > call_default(foo); > > Totally contrived, but this complains. Liberally sprinkling {} also shuts > up the compiler, but it's a

Re: [Intel-gfx] [PATCH 11/12] sched: use for_each_if in topology.h

On Mon, Jul 9, 2018 at 6:03 PM, Peter Zijlstra wrote: > On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote: >> for_each_something(foo) >> if (foo->bla) >> call_bla(foo); >> else >> call_default(foo); >> >> Totally contrived, but this complains. Li

  1   2   >