[Intel-gfx] [PATCH 2/3] drm/i915/gt: Perform an arbitration check before busywaiting

2021-01-10 Thread Chris Wilson
During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset preparations) on the first request afterwards. There was no explicit MI_ARB_CHECK in this sequence as the presumption was that the failed MI_SE

[Intel-gfx] [PATCH 3/3] drm/i915/selftests: Include engine name after reset failure

2021-01-10 Thread Chris Wilson
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the next time this happens, mention which engine that was. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/

[Intel-gfx] [PATCH 1/3] drm/i915/gt: Check for arbitration after writing start seqno

2021-01-10 Thread Chris Wilson
On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make the decisions as to how to process that CS ev

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/gt: Check for arbitration after writing start seqno

2021-01-10 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/gt: Check for arbitration after writing start seqno URL : https://patchwork.freedesktop.org/series/85674/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9573 -> Patchwork_19310 ===

[Intel-gfx] [PATCH 04/11] drm/i915/gt: Rearrange vlv workarounds

2021-01-10 Thread Chris Wilson
Some rcs0 workarounds were being incorrectly applied to the GT, and so we failed to restore the expected register settings after a reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 95 +++-- 1 file changed, 51 insertions(+), 44 deletions(-) dif

[Intel-gfx] [PATCH 05/11] drm/i915/gt: Rearrange ivb workarounds

2021-01-10 Thread Chris Wilson
Some rcs0 workarounds were being incorrectly applied to the GT, and so we failed to restore the expected register settings after a reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 122 1 file changed, 49 insertions(+), 73 deletions(-) dif

[Intel-gfx] [PATCH 06/11] drm/i915/gt: Replace open-coded intel_engine_stop_cs()

2021-01-10 Thread Chris Wilson
In the legacy ringbuffer submission, we still had an open-coded version of intel_engine_stop_cs() with one addition verification step. Transfer that verification to intel_engine_stop_cs() itself, and call it. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15

[Intel-gfx] [PATCH 09/11] drm/i915/gt: Pull ring submission resume under its caller forcewake

2021-01-10 Thread Chris Wilson
Take advantage of calling xcs_resume under a forcewake by using direct mmio access. In particular, we can avoid the sleeping variants to allow resume to be called from softirq context, required for engine resets. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/gt/intel_ring_submission.c | 96

[Intel-gfx] [PATCH 08/11] drm/i915/gt: Lift stop_ring() to reset_prepare

2021-01-10 Thread Chris Wilson
Push the sleeping stop_ring() out of the reset resume function to reset prepare; we are not allowed to sleep in the former. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/gt/intel_ring_submission.c | 97 +++ 1 file changed, 36 insertions(+), 61 deletions(-) diff --git a/driv

[Intel-gfx] [PATCH 10/11] drm/i915/selftests: Prepare the selftests for engine resets with ring submission

2021-01-10 Thread Chris Wilson
The engine resets selftests kick the tasklets, safe up until now as only execlists supported engine resets. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 18 ++ drivers/gpu/drm/i915/gt/selftest_reset.c | 11 --- 2 files changed, 22 ins

[Intel-gfx] [PATCH 11/11] drm/i915: Mark per-engine-reset as supported on gen7

2021-01-10 Thread Chris Wilson
The benefit of only resetting a single engine is that we leave other streams of userspace work intact across a hang; vital for process isolation. We had wired up individual engine resets for gen6, but only enabled it from gen8; now let's turn it on for the forgotten gen7. gen6 is still a mystery as

[Intel-gfx] [PATCH 07/11] drm/i915/gt: Reapply ppgtt enabling after engine resets

2021-01-10 Thread Chris Wilson
The GFX_MODE is reset along with the engine, turning off ppGTT. We need to re-enable it upon resume. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 9 - drivers/gpu/drm/i915/gt/intel_ring_submission.c | 13 ++--- 2 files changed, 10 insertions(

[Intel-gfx] [PATCH 02/11] drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail

2021-01-10 Thread Chris Wilson
The mitigation is required for all gen7 platforms, now that it does not cause GPU hangs, restore it for Ivybridge and Baytrail. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Prathap Kumar Valsan Cc: Akeem G Abodunrin

[Intel-gfx] [PATCH 01/11] drm/i915/gt: Limit VFE threads based on GT

2021-01-10 Thread Chris Wilson
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the range [0, n-1] where n is #EU * (#threads/EU) with the number of threads based on plaform and the number of EU based on the number of slices and subslices. This is a fixed number per platform/gt, so appropriately limit the number o

[Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override security mitigations

2021-01-10 Thread Chris Wilson
The clear-residuals mitigation is a relatively heavy hammer and under some circumstances the user may wish to forgo the context isolation in order to meet some performance requirement. Introduce a generic module parameter to allow selectively enabling/disabling different mitigations. Closes: https

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT

2021-01-10 Thread Patchwork
== Series Details == Series: series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT URL : https://patchwork.freedesktop.org/series/85682/ State : warning == Summary == $ dim checkpatch origin/drm-tip b57630875319 drm/i915/gt: Limit VFE threads based on GT 3de2a3eaddac drm/i915

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT

2021-01-10 Thread Patchwork
== Series Details == Series: series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT URL : https://patchwork.freedesktop.org/series/85682/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separa

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT

2021-01-10 Thread Patchwork
== Series Details == Series: series starting with [01/11] drm/i915/gt: Limit VFE threads based on GT URL : https://patchwork.freedesktop.org/series/85682/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9573 -> Patchwork_19311

Re: [Intel-gfx] linux-next: build failure after merge of the drm tree

2021-01-10 Thread Stephen Rothwell
Hi all, On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell wrote: > > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell > wrote: > > > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > error: the following would cause module name confl