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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8825_full -> Patchwork_18290_full Summary ---

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : success == Summary == CI Bug Log - changes from CI_DRM_8825 -> Patchwork_18290 Summary ---

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_perf.c:3281: warning: Function parameter or member 'cmd' not

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ 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 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

- Fixes a memory corruption due to addition of OA whitelist on demand. - Spinlock when applying whitelist 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:

[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] [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) v4: Use

[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] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8823_full -> Patchwork_18289_full

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18288_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool

== Series Details == Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool URL : https://patchwork.freedesktop.org/series/80147/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18287_full

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: timeline semaphore support

== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18286_full Summary ---

Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support

On 31/07/2020 17:32, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-07-31 14:45:52) Introduces a new parameters to execbuf so that we can specify syncobj handles as well as timeline points. v2: Reuse i915_user_extension_fn v3: Check that the chained extension is only present once (Chris)

Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support

On 31/07/2020 17:30, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-07-31 14:45:52) - drm_syncobj_replace_fence(syncobj, fence); + if (eb->fences[n].chain_fence) { + drm_syncobj_add_point(syncobj, eb->fences[n].chain_fence, +

[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes and improvements for Xen pvdrm

== Series Details == Series: Fixes and improvements for Xen pvdrm URL : https://patchwork.freedesktop.org/series/80141/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18285_full Summary ---

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

Quoting Tvrtko Ursulin (2020-07-31 17:06:08) > > On 31/07/2020 16:21, Chris Wilson wrote: > > Quoting Chris Wilson (2020-07-31 16:12:32) > >> Quoting Tvrtko Ursulin (2020-07-31 16:06:55) > >>> > >>> On 30/07/2020 10:37, Chris Wilson wrote: > @@ -191,17 +188,19 @@ static void

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake

== Series Details == Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake URL : https://patchwork.freedesktop.org/series/80139/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18284_full

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : success == Summary == CI Bug Log - changes from CI_DRM_8823 -> Patchwork_18289

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used,

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8bec68a2d4fc drm/i915: Remove requirement

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

On 31/07/2020 16:21, Chris Wilson wrote: Quoting Chris Wilson (2020-07-31 16:12:32) Quoting Tvrtko Ursulin (2020-07-31 16:06:55) On 30/07/2020 10:37, Chris Wilson wrote: @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work) { struct intel_breadcrumbs *b =

[Intel-gfx] [CI 4/4] 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] [CI 1/4] 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] [CI 3/4] 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] [CI 2/4] 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

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

On 31/07/2020 16:24, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-07-31 16:15:43) On 30/07/2020 10:37, Chris Wilson wrote: 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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Drop stale timeline constructor assert

== Series Details == Series: drm/i915/selftests: Drop stale timeline constructor assert URL : https://patchwork.freedesktop.org/series/80138/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8821_full -> Patchwork_18282_full

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

On 31/07/2020 16:12, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-07-31 16:06:55) On 30/07/2020 10:37, Chris Wilson wrote: @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work) { struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);

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

Quoting Tvrtko Ursulin (2020-07-31 16:15:43) > > On 30/07/2020 10:37, Chris Wilson wrote: > > 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,

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18288 Summary ---

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

Quoting Chris Wilson (2020-07-31 16:12:32) > Quoting Tvrtko Ursulin (2020-07-31 16:06:55) > > > > On 30/07/2020 10:37, Chris Wilson wrote: > > > @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work) > > > { > > > struct intel_breadcrumbs *b = container_of(work,

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

On 30/07/2020 10:37, Chris Wilson wrote: 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

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

Quoting Tvrtko Ursulin (2020-07-31 16:06:55) > > On 30/07/2020 10:37, Chris Wilson wrote: > > @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work) > > { > > struct intel_breadcrumbs *b = container_of(work, typeof(*b), > > irq_work); > > const ktime_t timestamp =

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_perf.c:3281: warning: Function parameter or member 'cmd' not

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

On 30/07/2020 10:37, Chris Wilson wrote: 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

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

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ 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 Allow privileged user to map the OA buffer

== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5b0cda02e636 drm/i915/perf: Ensure observation logic is not clock gated c203e309db25 drm/i915/perf:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool

== Series Details == Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool URL : https://patchwork.freedesktop.org/series/80147/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18287

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

Quoting Umesh Nerlige Ramappa (2020-07-31 15:46:43) > 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,

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

On 30/07/2020 10:37, Chris Wilson wrote: 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

[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] [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) v4: Use

[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 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] ✓ Fi.CI.IGT: success for series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini()

== Series Details == Series: series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80136/ State : success == Summary == CI Bug Log - changes from CI_DRM_8821_full -> Patchwork_18281_full

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool

== Series Details == Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool URL : https://patchwork.freedesktop.org/series/80147/ 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.BAT: success for drm/i915: timeline semaphore support

== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18286 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support

Quoting Lionel Landwerlin (2020-07-31 14:45:52) > Introduces a new parameters to execbuf so that we can specify syncobj > handles as well as timeline points. > > v2: Reuse i915_user_extension_fn > > v3: Check that the chained extension is only present once (Chris) > > v4: Check that

Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support

Quoting Lionel Landwerlin (2020-07-31 14:45:52) > - drm_syncobj_replace_fence(syncobj, fence); > + if (eb->fences[n].chain_fence) { > + drm_syncobj_add_point(syncobj, > eb->fences[n].chain_fence, > +

Re: [Intel-gfx] [PATCH] drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool

Quoting Chris Wilson (2020-07-31 15:12:45) > Make sure that the obj->base.resv does not hold a reference to a fence > that itself has an active reference on the object. There is no automatic The active reference is pruned. I was thinking of other reference cycles that may exist, but I do not

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: timeline semaphore support

== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ 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 drm/i915: timeline semaphore support

== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1d1036f097fd drm/i915: introduce a mechanism to extend execbuf2 -:377: CHECK:SPACING: spaces preferred around

[Intel-gfx] [PATCH] drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool

Make sure that the obj->base.resv does not hold a reference to a fence that itself has an active reference on the object. There is no automatic pruning, so we must decouple such reference cycles (just in case they exist) before discarding the pool->obj. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2

We're planning to use this for a couple of new feature where we need to provide additional parameters to execbuf. v2: Check for invalid flags in execbuffer2 (Lionel) v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris) v4: Rebase Move array fence parsing in i915_gem_do_execbuffer()

[Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support

Introduces a new parameters to execbuf so that we can specify syncobj handles as well as timeline points. v2: Reuse i915_user_extension_fn v3: Check that the chained extension is only present once (Chris) v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel) v5: Use

[Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences

To allow faster engine to engine synchronization, peel the layer of dma-fence-chain to expose potential i915 fences so that the i915-request code can emit HW semaphore wait/signal operations in the ring which is faster than waking up the host to submit unblocked workloads after interrupt

[Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support

Hi all, Reviewed series, just getting a CI run with the CI. Cheers, Test-with: 20200731134120.156288-1-lionel.g.landwer...@intel.com Lionel Landwerlin (3): drm/i915: introduce a mechanism to extend execbuf2 drm/i915: add syncobj timeline support drm/i915: peel dma-fence-chains wait

Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker

On 7/31/20 3:28 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-31 10:03:59) On 7/15/20 1:50 PM, Chris Wilson wrote: Currently, if an error is raised we always call the cleanup locally [and skip the main work callback]. However, some future users Could you add an example of

[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes and improvements for Xen pvdrm

== Series Details == Series: Fixes and improvements for Xen pvdrm URL : https://patchwork.freedesktop.org/series/80141/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18285 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker

Quoting Thomas Hellström (Intel) (2020-07-31 10:03:59) > > On 7/15/20 1:50 PM, Chris Wilson wrote: > > Currently, if an error is raised we always call the cleanup locally > > [and skip the main work callback]. However, some future users > Could you add an example of those future users? In the

Re: [Intel-gfx] [PATCH 22/66] drm/i915/gem: Bind the fence async for execbuf

On 7/28/20 5:08 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-27 19:19:19) On 7/15/20 1:51 PM, Chris Wilson wrote: It is illegal to wait on an another vma while holding the vm->mutex, as that easily leads to ABBA deadlocks (we wait on a second vma that waits on us to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes and improvements for Xen pvdrm

== Series Details == Series: Fixes and improvements for Xen pvdrm URL : https://patchwork.freedesktop.org/series/80141/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7d48f149439c xen/gntdev: Fix dmabuf import with non-zero sgt offset -:10: WARNING:UNKNOWN_COMMIT_ID: Unknown

Re: [Intel-gfx] [PATCH 21/66] drm/i915/gem: Asynchronous GTT unbinding

On 7/15/20 1:51 PM, Chris Wilson wrote: It is reasonably common for userspace (even modern drivers like iris) to reuse an active address for a new buffer. This would cause the application to stall under its mutex (originally struct_mutex) until the old batches were idle and it could

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake

== Series Details == Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake URL : https://patchwork.freedesktop.org/series/80139/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18284

[Intel-gfx] [PATCH 1/6] xen/gntdev: Fix dmabuf import with non-zero sgt offset

From: Oleksandr Andrushchenko It is possible that the scatter-gather table during dmabuf import has non-zero offset of the data, but user-space doesn't expect that. Fix this by failing the import, so user-space doesn't access wrong data. Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf

[Intel-gfx] [PATCH 6/6] drm/xen-front: Add support for EDID based configuration

From: Oleksandr Andrushchenko Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID request which allows frontends to request EDID structure per connector. This request is optional and if not supported by the backend then visible area is still defined by the relevant XenStore's

[Intel-gfx] [PATCH 0/6] Fixes and improvements for Xen pvdrm

From: Oleksandr Andrushchenko Hello, This series contains an assorted set of fixes and improvements for the Xen para-virtualized display driver and grant device driver which I have collected over the last couple of months: 1. Minor fixes to grant device driver and drm/xen-front. 2. New format

[Intel-gfx] [PATCH 4/6] xen: Sync up with the canonical protocol definition in Xen

From: Oleksandr Andrushchenko This is the sync up with the canonical definition of the display protocol in Xen. 1. Add protocol version as an integer Version string, which is in fact an integer, is hard to handle in the code that supports different protocol versions. To simplify that also add

[Intel-gfx] [PATCH 5/6] drm/xen-front: Pass dumb buffer data offset to the backend

From: Oleksandr Andrushchenko While importing a dmabuf it is possible that the data of the buffer is put with offset which is indicated by the SGT offset. Respect the offset value and forward it to the backend. Signed-off-by: Oleksandr Andrushchenko --- drivers/gpu/drm/xen/xen_drm_front.c

[Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks

From: Oleksandr Andrushchenko The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend" from Apr 3, 2018, leads to the following static checker warning: drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create() warn: passing zero to 'ERR_CAST'

[Intel-gfx] [PATCH 3/6] drm/xen-front: Add YUYV to supported formats

From: Oleksandr Andrushchenko Add YUYV to supported formats, so the frontend can work with the formats used by cameras and other HW. Signed-off-by: Oleksandr Andrushchenko --- drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake

== Series Details == Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake URL : https://patchwork.freedesktop.org/series/80139/ 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.BAT: success for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3)

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

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

== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3) 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] [PATCH 1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake

Bump TGL DMC version to 2.07. This new version has power saving enhancements. Cc: José Roberto de Souza Signed-off-by: Anusha Srivatsa Reviewed-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Load DMC firmware v2.02 for Rocket Lake

The latest firmware contains fix for PSR2 power saving. Cc: Matt Roper Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Drop stale timeline constructor assert

== Series Details == Series: drm/i915/selftests: Drop stale timeline constructor assert URL : https://patchwork.freedesktop.org/series/80138/ State : success == Summary == CI Bug Log - changes from CI_DRM_8821 -> Patchwork_18282 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Drop stale timeline constructor assert

== Series Details == Series: drm/i915/selftests: Drop stale timeline constructor assert URL : https://patchwork.freedesktop.org/series/80138/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 33/66] drm/i915: Remove unused i915_gem_evict_vm()

On 7/15/20 1:51 PM, Chris Wilson wrote: Obsolete, last user removed. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 32/66] drm/i915/gt: Push the wait for the context to bound to the request

On 7/15/20 1:51 PM, Chris Wilson wrote: Rather than synchronously wait for the context to be bound, within the intel_context_pin(), we can track the pending completion of the bind fence and only submit requests along the context when signaled. Signed-off-by: Chris Wilson Reviewed-by: Thomas

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

== Series Details == Series: series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80136/ State : success == Summary == CI Bug Log - changes from CI_DRM_8821 -> Patchwork_18281

Re: [Intel-gfx] [PATCH 31/66] drm/i915/gt: Acquire backing storage for the context

On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the individual acquisition of the context objects (state, ring, timeline) under a common i915_acquire_ctx in preparation to allow the context to evict memory (or rather the i915_acquire_ctx on its behalf). The context objects maintain their

[Intel-gfx] [PATCH] drm/i915/selftests: Drop stale timeline constructor assert

Since we pass around encoded parameters to the kernel context constructor using the ce->timeline pointer, we can no longer assert that it should be zero for mock timeline construction. Fixes: cffef56a43bb ("drm/i915/gt: Support multiple pinned timelines") Signed-off-by: Chris Wilson ---

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

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

Re: [Intel-gfx] [PATCH 29/66] drm/i915: Hold wakeref for the duration of the vma GGTT binding

On 7/15/20 1:51 PM, Chris Wilson wrote: Now that we have pushed the binding itself outside of the vm->mutex, we are clear of the potential wakeref inversions and can take the wakeref around the actual duration of the HW interaction. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström

Re: [Intel-gfx] [PATCH 26/66] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.

On 7/15/20 1:51 PM, Chris Wilson wrote: From: Maarten Lankhorst i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory eviction. We don't use it yet, but lets start adding the definition first. To use it, we have to pass a non-NULL ww to gem_object_lock, and don't unlock

Re: [Intel-gfx] [PATCH 25/66] drm/i915/gem: Reintroduce multiple passes for reloc processing

On 7/15/20 1:51 PM, Chris Wilson wrote: The prospect of locking the entire submission sequence under a wide ww_mutex re-imposes some key restrictions, in particular that we must not call copy_(from|to)_user underneath the mutex (as the faulthandlers themselves may need to take the ww_mutex).

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_ringsize: Manually control timeout

On Fri, 31 Jul 2020 at 10:15, Chris Wilson wrote: > > Manually setup the signal handler for SIGARLM so that we can dump some > debug information for test failures. > > Signed-off-by: Chris Wilson Acked-by: Matthew Auld ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 24/66] drm/i915/gem: Include secure batch in common execbuf pinning

On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the GGTT binding for the secure batch dispatch into the common vma pinning routine for execbuf, so that there is just a single central place for all i915_vma_pin(). Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström

Re: [Intel-gfx] [PATCH 23/66] drm/i915/gem: Include cmdparser in common execbuf pinning

On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the cmdparser allocations in to the reservation phase, and then they are included in the common vma pinning pass. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list

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

Quoting Umesh Nerlige Ramappa (2020-07-31 07:07:23) > 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,

Re: [Intel-gfx] [PATCH 20/66] drm/i915/gem: Separate the ww_mutex walker into its own list

On 7/15/20 1:51 PM, Chris Wilson wrote: In preparation for making eb_vma bigger and heavy to run in parallel, we need to stop applying an in-place swap() to reorder around ww_mutex deadlocks. Keep the array intact and reorder the locks using a dedicated list. Signed-off-by: Chris Wilson

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

Quoting Umesh Nerlige Ramappa (2020-07-31 07:07:20) > 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

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_ringsize: Manually control timeout

Manually setup the signal handler for SIGARLM so that we can dump some debug information for test failures. Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_ringsize.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/tests/i915/gem_ctx_ringsize.c

Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker

On 7/15/20 1:50 PM, Chris Wilson wrote: Currently, if an error is raised we always call the cleanup locally [and skip the main work callback]. However, some future users Could you add an example of those future users? may need to take a mutex to cleanup and so we cannot immediately execute

Re: [Intel-gfx] [PATCH 17/66] drm/i915: Add list_for_each_entry_safe_continue_reverse

On 7/15/20 1:50 PM, Chris Wilson wrote: One more list iterator variant, for when we want to unwind from inside one list iterator with the intention of restarting from the current entry as the new head of the list. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Reviewed-by: Thomas

Re: [Intel-gfx] [PATCH 16/66] drm/i915/gem: Remove the call for no-evict i915_vma_pin

On 7/28/20 5:05 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-28 10:46:51) On 7/15/20 1:50 PM, Chris Wilson wrote: Remove the stub i915_vma_pin() used for incrementally pining objects for s/pining/pinning/ Pining for the fjords. -Chris Apart from that, Reviewed-by:

  1   2   >