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

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

[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

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

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

[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

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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

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

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

[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

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

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

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

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

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

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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

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

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

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

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

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(>lock); > > + /* > +* User could have multiple vmas from multiple

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 = >whitelist; > + struct drm_i915_private *i915 = engine->i915; > + > + if (IS_GEN(i915, 12)) > +

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

Re: [Intel-gfx] [PATCH] drm/i915: Avoid modeset when content protection changes

On 2020-07-14 at 21:36:27 +0530, Sean Paul wrote: > From: Sean Paul > > Instead of doing a full modeset to enable/disable content protection, > simply go through the update_pipe flow which was introduced in the > related patch below. This avoids flashing the screen every time the user > starts