Re: [Intel-gfx] [PATCH] drm/i915/display: Check for an LPSP encoder before dereferencing

On 2020-07-29 at 14:09:12 +0100, Chris Wilson wrote: > Avoid a GPF at > > <1>[ 20.177320] BUG: kernel NULL pointer dereference, address: > 007c > <1>[ 20.177322] #PF: supervisor read access in kernel mode > <1>[ 20.177323] #PF: error_code(0x) - not-present page > <6>[ 20.1

Re: [Intel-gfx] [PATCH 4/6] drm/i915/perf: Whitelist OA report trigger registers

Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:24) > +void intel_engine_apply_oa_whitelist(struct intel_engine_cs *engine) > +{ > + struct i915_wa_list *w = &engine->whitelist; > + struct drm_i915_private *i915 = engine->i915; > + > + if (IS_GEN(i915, 12)) > + white

Re: [Intel-gfx] [PATCH 6/6] drm/i915/perf: Map OA buffer to user space for gen12 performance query

Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:26) > @@ -3318,12 +3354,87 @@ static int i915_perf_release(struct inode *inode, > struct file *file) > i915_perf_destroy_locked(stream); > mutex_unlock(&perf->lock); > > + /* > +* User could have multiple vmas from mul

Re: [Intel-gfx] [PATCH 6/6] drm/i915/perf: Map OA buffer to user space for gen12 performance query

Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:26) > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 00546062e023..36f6b9799ecd 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -2048,6 +20

Re: [Intel-gfx] [PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

On Wed, Jul 29, 2020 at 11:32:28AM +0200, Hans de Goede wrote: > cHi, > > On 7/29/20 10:23 AM, Andy Shevchenko wrote: > > On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote: > > > On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote: > > > > > I've applied patches 3 through 1

[Intel-gfx] [CI] drm/i915/gem: Delay tracking the GEM context until it is registered

Avoid exposing a partially constructed context by deferring the list_add() from the initial construction to the end of registration. Otherwise, if we peek into the list of contexts from inside debugfs, we may see the partially constructed context and chase down some dangling incomplete pointers. R

[Intel-gfx] [PATCH 17/21] drm/i915/gt: Protect context lifetime with RCU

Allow a brief period for continued access to a dead intel_context by deferring the release of the struct until after an RCU grace period. As we are using a dedicated slab cache for the contexts, we can defer the release of the slab pages via RCU, with the caveat that individual structs may be reuse

[Intel-gfx] [PATCH 20/21] drm/i915: Drop i915_request.lock requirement for intel_rps_boost()

Since we use a flag within i915_request.flags to indicate when we have boosted the request (so that we only apply the boost) once, this can be used as the serialisation with i915_request_retire() to avoid having to explicitly take the i915_request.lock which is more heavily contended. Signed-off-b

[Intel-gfx] [PATCH 02/21] drm/i915: Skip taking acquire mutex for no ref->active callback

If no active callback is defined for i915_active, we do not need to serialise its enabling with the mutex. We still do only want to call the debug activate once, and must still serialise with a concurrent retire. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Reviewed-by: Thomas Hellstr

[Intel-gfx] [PATCH 08/21] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source

When cloning the engines from the source context, we need to ensure that the engines are not freed as we copy them, and that the flags we clone from the source correspond with the engines we copy across. To do this we need only take a reference to the src->engines, rather than hold the src->engine_

[Intel-gfx] [PATCH 07/21] drm/i915: Provide a fastpath for waiting on vma bindings

Before we can execute a request, we must wait for all of its vma to be bound. This is a frequent operation for which we can optimise away a few atomic operations (notably a cmpxchg) in lieu of the RCU protection. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström Reviewed-by: Tvrtko Ursul

[Intel-gfx] [PATCH 12/21] drm/i915/gt: Only transfer the virtual context to the new engine if active

One more complication of preempt-to-busy with respect to the virtual engine is that we may have retired the last request along the virtual engine at the same time as preparing to submit the completed request to a new engine. That submit will be shortcircuited, but not before we have updated the con

[Intel-gfx] [PATCH 21/21] drm/i915/gem: Delay tracking the GEM context until it is registered

Avoid exposing a partially constructed context by deferring the list_add() from the initial construction to the end of registration. Otherwise, if we peek into the list of contexts from inside debugfs, we may see the partially constructed context and chase down some dangling incomplete pointers. R

[Intel-gfx] [PATCH 14/21] drm/i915/gt: Move intel_breadcrumbs_arm_irq earlier

Move the __intel_breadcrumbs_arm_irq earlier, next to the disarm_irq, so that we can make use of it in the following patch. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 84 ++--- 1 file changed, 42 insertions(+), 42 de

[Intel-gfx] Breadcrumbs fixes and stall avoidance

All the breadcrumb fixes and low hanging fruit from staring at perf and lockstat for too long to minimise the delays during submission. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/inte

[Intel-gfx] [PATCH 13/21] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs

On the virtual engines, we only use the intel_breadcrumbs for tracking signaling of stale breadcrumbs from the irq_workers. They do not have any associated interrupt handling, active requests are passed to a physical engine and associated breadcrumb interrupt handler. This causes issues for us as w

[Intel-gfx] [PATCH 04/21] drm/i915: Keep the most recently used active-fence upon discard

Whenever an i915_active idles, we prune its tree of old fence slots to prevent a gradual leak should it be used to track many, many timelines. The downside is that we then have to frequently reallocate the rbtree. A compromise is that we keep the most recently used fence slot, and reuse that for th

[Intel-gfx] [PATCH 09/21] drm/i915/gem: Reduce ctx->engines_mutex for get_engines()

Take a snapshot of the ctx->engines, so we can avoid taking the ctx->engines_mutex for a mere read in get_engines(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 + 1 file changed, 8 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/

[Intel-gfx] [PATCH 05/21] drm/i915: Make the stale cached active node available for any timeline

Rather than require the next timeline after idling to match the MRU before idling, reset the index on the node and allow it to match the first request. However, this requires cmpxchg(u64) and so is not trivial on 32b, so for compatibility we just fallback to keeping the cached node pointing to the

[Intel-gfx] [PATCH 01/21] drm/i915: Add a couple of missing i915_active_fini()

We use i915_active_fini() as a debug check on the i915_active state before freeing. If we forget to call it, we may end up angering the debugobjects contained within. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/display/intel_fr

[Intel-gfx] [PATCH 06/21] drm/i915: Reduce locking around i915_active_acquire_preallocate_barrier()

As the conversion between idle-barrier and full i915_active_fence is already serialised by explicit memory barriers, we can reduce the spinlock in i915_active_acquire_preallocate_barrier() for finding an idle-barrier to reuse to an RCU read lock to ensure the fence remains valid, only taking the sp

[Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock

Make b->signaled_requests a lockless-list so that we can manipulate it outside of the b->irq_lock. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 30 +++ .../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +- drivers/gpu/drm/i915/i915_request.h

[Intel-gfx] [PATCH 18/21] drm/i915/gt: Split the breadcrumb spinlock between global and contexts

As we funnel more and more contexts into the breadcrumbs on an engine, the hold time of b->irq_lock grows. As we may then contend with the b->irq_lock during request submission, this increases the burden upon the engine->active.lock and so directly impacts both our execution latency and client late

[Intel-gfx] [PATCH 03/21] drm/i915: Export a preallocate variant of i915_active_acquire()

Sometimes we have to be very careful not to allocate underneath a mutex (or spinlock) and yet still want to track activity. Enter i915_active_acquire_for_context(). This raises the activity counter on i915_active prior to use and ensures that the fence-tree contains a slot for the context. v2: Ref

[Intel-gfx] [PATCH 19/21] drm/i915: Drop i915_request.lock serialisation around await_start

Originally, we used the signal->lock as a means of following the previous link in its timeline and peeking at the previous fence. However, we have replaced the explicit serialisation with a series of very careful probes that anticipate the links being deleted and the fences recycled before we are a

[Intel-gfx] [PATCH 10/21] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

Since the breadcrumb enabling/cancelling itself is serialised by the breadcrumbs.irq_lock, with a bit of care we can remove the outer serialisation with i915_request.lock for concurrent dma_fence_enable_signaling(). This has the important side-effect of eliminating the nested i915_request.lock with

[Intel-gfx] [PATCH 15/21] drm/i915/gt: Hold context/request reference while breadcrumbs are active

Currently we hold no actual reference to the request nor context while they are attached to a breadcrumb. To avoid freeing the request/context too early, we serialise with cancel-breadcrumbs by taking the irq spinlock in i915_request_retire(). The alternative is to take a reference for a new breadc

[Intel-gfx] [PATCH 11/21] drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs

After staring at the breadcrumb enabling/cancellation and coming to the conclusion that the cause of the mysterious stale breadcrumbs must the act of submitting a completed requests, we can then redirect those completed requests onto a dedicated signaled_list at the time of construction and so elim

[Intel-gfx] [PATCH 1/2] i915/debug: Expose crtc dither state via debugfs

[Why] It's useful to know the dithering state for IGT testing. [How] Expose the dithering state for the crtc via a debugfs file "dither". Example usage: cat /sys/kernel/debug/dri/0/crtc-0/dither Cc: Uma Shankar Cc: Rodrigo Vivi Signed-off-by: Bhanuprakash Modem --- drivers/gpu/drm/i915/i915_

[Intel-gfx] [PATCH 2/2] i915/debug: Expose Max BPC info via debugfs

[Why] It's useful to know the max supported panel BPC for IGT testing. [How] Expose the max supported BPC for the panel via a debugfs file on the connector, "output_bpc". Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Cc: Uma Shankar Cc: Rodrigo Vivi Signed-off-by: Bhanuprakash Mod

[Intel-gfx] [PATCH 0/2] Expose crtc dither state and connector max bpc via debugfs

[why] It's useful to know the max supported panel BPC and PIPE dither state for IGT testing. [how] * Expose the connector max supported BPC for the panel via a debugfs file on the connector, "output_bpc". Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc * Expose the dithering state for th

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Delay tracking the GEM context until it is registered (rev3)

== Series Details == Series: drm/i915/gem: Delay tracking the GEM context until it is registered (rev3) URL : https://patchwork.freedesktop.org/series/79822/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked se

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Delay tracking the GEM context until it is registered (rev3)

== Series Details == Series: drm/i915/gem: Delay tracking the GEM context until it is registered (rev3) URL : https://patchwork.freedesktop.org/series/79822/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9e47bf80906a drm/i915/gem: Delay tracking the GEM context until it is reg

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Delay tracking the GEM context until it is registered (rev3)

== Series Details == Series: drm/i915/gem: Delay tracking the GEM context until it is registered (rev3) URL : https://patchwork.freedesktop.org/series/79822/ State : success == Summary == CI Bug Log - changes from CI_DRM_8815 -> Patchwork_18270

Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

On 7/28/20 4:50 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-27 10:24:24) Hi, Chris, It appears to me like this series is doing a lot of different things: - Various optimizations - Locking rework - Adding schedulers - Other misc fixes Could you please separate out as mu

Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

On 7/28/20 3:58 PM, Daniel Vetter wrote: GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers. So full hierarchy is now (ignore some of the other branches we al

Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

On 7/28/20 4:50 PM, Chris Wilson wrote: It's in the user critical path (the shortest path to perform their sequence of operations), but it's before the dma-fence itself. I say that's a particularly nasty false claim that it is not on the critical path, but being where it is circumvents the who

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

Am 28.07.20 um 15:58 schrieb Daniel Vetter: GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers. So full hierarchy is now (ignore some of the other branches we a

Re: [Intel-gfx] [PATCH 27/66] drm/i915/gem: Pull execbuf dma resv under a single critical section

On 7/28/20 5:16 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-27 19:08:39) On 7/15/20 1:51 PM, Chris Wilson wrote: Acquire all the objects and their backing storage, and page directories, as used by execbuf under a single common ww_mutex. Albeit we have to restart the criti

Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel) wrote: > > > On 7/28/20 3:58 PM, Daniel Vetter wrote: > > GPU drivers need this in their shrinkers, to be able to throw out > > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, > > but that loop is resolved by trylocking i

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Delay tracking the GEM context until it is registered (rev3)

== Series Details == Series: drm/i915/gem: Delay tracking the GEM context until it is registered (rev3) URL : https://patchwork.freedesktop.org/series/79822/ State : success == Summary == CI Bug Log - changes from CI_DRM_8815_full -> Patchwork_18270_full ==

[Intel-gfx] [PATCH] drm/i915/gt: Pull release of node->age under the spinlock

We need to ensure that the list is valid prior to marking the node as retrievable, otherwise we may see two threads compete over the same node in intel_gt_get_buffer_pool(). If the first thread acquires and releases the node in the same jiffie, the second thread may then acquire it (as the jiffie n

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

== Series Details == Series: series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80083/ State : warning == Summary == $ dim checkpatch origin/drm-tip a0fa9abdd53b drm/i915: Add a couple of missing i915_active_fini()

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

== Series Details == Series: series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80083/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be che

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

== Series Details == Series: series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80083/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18271 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Expose crtc dither state and connector max bpc via debugfs (rev4)

== Series Details == Series: Expose crtc dither state and connector max bpc via debugfs (rev4) URL : https://patchwork.freedesktop.org/series/79664/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose crtc dither state and connector max bpc via debugfs (rev4)

== Series Details == Series: Expose crtc dither state and connector max bpc via debugfs (rev4) URL : https://patchwork.freedesktop.org/series/79664/ State : warning == Summary == $ dim checkpatch origin/drm-tip f05f2b52683b i915/debug: Expose crtc dither state via debugfs -:47: WARNING:SYMBOLI

[Intel-gfx] ✓ Fi.CI.BAT: success for Expose crtc dither state and connector max bpc via debugfs (rev4)

== Series Details == Series: Expose crtc dither state and connector max bpc via debugfs (rev4) URL : https://patchwork.freedesktop.org/series/79664/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18272 Summ

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Pull release of node->age under the spinlock

== Series Details == Series: drm/i915/gt: Pull release of node->age under the spinlock URL : https://patchwork.freedesktop.org/series/80094/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Pull release of node->age under the spinlock

== Series Details == Series: drm/i915/gt: Pull release of node->age under the spinlock URL : https://patchwork.freedesktop.org/series/80094/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18273 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2) URL : https://patchwork.freedesktop.org/series/80045/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit wo

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2) URL : https://patchwork.freedesktop.org/series/80045/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18274 ===

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

Hi Dave & Daniel, (Covering for Jani here for drm-intel-next-fixes) 5 new commits over drm-intel-next here. Fix for KASAN detected race condition and linux-next scheduler WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU refcount update. CI machinery needed some kicking, so results didn't a

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev5)

I verified igt@kms_frontbuffer_tracking@basic with and without this patch on my local build and observed that test is passing in both cases. Test result with 9694a4caf26c drm-tip: 2020y-07m-30d-12h-33m-57s UTC integration manifest $ sudo ./build/tests/kms_frontbuffer_tracking --r basic IGT-Vers

Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

On 7/30/20 3:17 PM, Daniel Vetter wrote: On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel) wrote: On 7/28/20 3:58 PM, Daniel Vetter wrote: GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loo

[Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

We may need to allocate more than one pinned context/timeline for each engine which can utilise the per-engine HWSP, if we give each a different offset within it. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c

Re: [Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

Quoting Chris Wilson (2020-07-30 17:47:57) > #include "i915_active.h" > #include "i915_syncmap.h" > -#include "gt/intel_timeline_types.h" > +#include "intel_timeline_types.h" > + > +#define global_hwsp(H, C) page_pack_bits(H, C) This argument packing did not survive. -Chris _

[Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

We may need to allocate more than one pinned context/timeline for each engine which can utilise the per-engine HWSP, so we need to give each a different offset within it. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines URL : https://patchwork.freedesktop.org/series/80098/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. _

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Support multiple pinned timelines

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines URL : https://patchwork.freedesktop.org/series/80098/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18275 Summary --- **SU

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines (rev2)

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines (rev2) URL : https://patchwork.freedesktop.org/series/80098/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Support multiple pinned timelines (rev2)

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines (rev2) URL : https://patchwork.freedesktop.org/series/80098/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18276 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

On Thu, 30 Jul 2020 at 17:52, Chris Wilson wrote: > > We may need to allocate more than one pinned context/timeline for each > engine which can utilise the per-engine HWSP, so we need to give each > a different offset within it. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld _

[Intel-gfx] [CI] drm/i915/gt: Support multiple pinned timelines

We may need to allocate more than one pinned context/timeline for each engine which can utilise the per-engine HWSP, so we need to give each a different offset within it. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20200730165231.545

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines (rev3)

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines (rev3) URL : https://patchwork.freedesktop.org/series/80098/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

== Series Details == Series: series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80083/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18271_full ===

[Intel-gfx] ✓ Fi.CI.IGT: success for Expose crtc dither state and connector max bpc via debugfs (rev4)

== Series Details == Series: Expose crtc dither state and connector max bpc via debugfs (rev4) URL : https://patchwork.freedesktop.org/series/79664/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18272_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Support multiple pinned timelines (rev3)

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines (rev3) URL : https://patchwork.freedesktop.org/series/80098/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18277 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/gt: Pull release of node->age under the spinlock

On Thu, 30 Jul 2020 at 14:41, Chris Wilson wrote: > > We need to ensure that the list is valid prior to marking the node as > retrievable, otherwise we may see two threads compete over the same node > in intel_gt_get_buffer_pool(). If the first thread acquires and releases > the node in the same j

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Pull release of node->age under the spinlock

== Series Details == Series: drm/i915/gt: Pull release of node->age under the spinlock URL : https://patchwork.freedesktop.org/series/80094/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18273_full Su

[Intel-gfx] [PATCH v4] Add support for KeemBay DRM driver

This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++-

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2) URL : https://patchwork.freedesktop.org/series/80045/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18274_full =

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kmb: Add support for KeemBay Display (rev2)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev2) URL : https://patchwork.freedesktop.org/series/79615/ State : warning == Summary == $ dim checkpatch origin/drm-tip 984b2ce8e7ed drm/kmb: Add support for KeemBay Display -:55: WARNING:FILE_PATH_CHANGES: added, moved o

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/kmb: Add support for KeemBay Display (rev2)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev2) URL : https://patchwork.freedesktop.org/series/79615/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18278 Summary --- **S

[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers

OA reports can be triggered into the OA buffer by writing into the OAREPORTTRIG registers. Whitelist the registers to allow non-privileged user to trigger reports. Whitelist registers only if perf_stream_paranoid is set to 0. In i915_perf_open_ioctl, this setting is checked and the whitelist is en

[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer

This cover letter is included to trigger "Test-with" an IGT patch. Tests - https://patchwork.freedesktop.org/series/80113/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200730230002.55737-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (1): drm/i915/perf: Ensure observation logic is n

[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated

From: Piotr Maciejewski A clock gating switch can control if the performance monitoring and observation logic is enaled or not. Ensure that we enable the clocks. v2: Separate code from other patches (Lionel) v3: Reset PMON enable when disabling perf to save power (Lionel) Fixes: 00a7f0d7155c ("

[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers

It is useful to have markers in the OA reports to identify triggered reports. Whitelist some OA counters that can be used as markers. A triggered report can be found faster if we can sample the HW tail and head registers when the report was triggered. Whitelist OA buffer specific registers. v2: -

[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query

i915 used to support time based sampling mode which is good for overall system monitoring, but is not enough for query mode used to measure a single draw call or dispatch. Gen9-Gen11 are using current i915 perf implementation for query, but Gen12+ requires a new approach for query based on triggere

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer (rev7)

== Series Details == Series: Allow privileged user to map the OA buffer (rev7) URL : https://patchwork.freedesktop.org/series/79460/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer (rev7)

== Series Details == Series: Allow privileged user to map the OA buffer (rev7) URL : https://patchwork.freedesktop.org/series/79460/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18279 Summary --- *

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Support multiple pinned timelines (rev3)

== Series Details == Series: drm/i915/gt: Support multiple pinned timelines (rev3) URL : https://patchwork.freedesktop.org/series/80098/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18277_full Summar

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/kmb: Add support for KeemBay Display (rev2)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev2) URL : https://patchwork.freedesktop.org/series/79615/ State : success == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18278_full Summary

[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow privileged user to map the OA buffer (rev7)

== Series Details == Series: Allow privileged user to map the OA buffer (rev7) URL : https://patchwork.freedesktop.org/series/79460/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18279_full Summary --

[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated

From: Piotr Maciejewski A clock gating switch can control if the performance monitoring and observation logic is enaled or not. Ensure that we enable the clocks. v2: Separate code from other patches (Lionel) v3: Reset PMON enable when disabling perf to save power (Lionel) Fixes: 00a7f0d7155c ("

[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers

It is useful to have markers in the OA reports to identify triggered reports. Whitelist some OA counters that can be used as markers. A triggered report can be found faster if we can sample the HW tail and head registers when the report was triggered. Whitelist OA buffer specific registers. v2: -

[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query

i915 used to support time based sampling mode which is good for overall system monitoring, but is not enough for query mode used to measure a single draw call or dispatch. Gen9-Gen11 are using current i915 perf implementation for query, but Gen12+ requires a new approach for query based on triggere

[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer

Fixes a memory corruption due to addition of OA whitelist on demand. This cover letter is included to trigger "Test-with" an IGT patch. Tests - https://patchwork.freedesktop.org/series/80113/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200730230002.55737-1-umesh.nerlige.rama...@intel.com

[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers

OA reports can be triggered into the OA buffer by writing into the OAREPORTTRIG registers. Whitelist the registers to allow non-privileged user to trigger reports. Whitelist registers only if perf_stream_paranoid is set to 0. In i915_perf_open_ioctl, this setting is checked and the whitelist is en

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer (rev8)

== Series Details == Series: Allow privileged user to map the OA buffer (rev8) URL : https://patchwork.freedesktop.org/series/79460/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer (rev8)

== Series Details == Series: Allow privileged user to map the OA buffer (rev8) URL : https://patchwork.freedesktop.org/series/79460/ State : success == Summary == CI Bug Log - changes from CI_DRM_8819 -> Patchwork_18280 Summary --- *