linux-stable.git/drivers/gpu/drm/i915/intel_ringbuffer.c, branch linux-4.6.y

drm/i915: Force ringbuffers to not be at offset 0

2016-04-18T09:35:51+00:00

For reasons unknown Sandybridge GT1 (at least) will eventually hang when
it encounters a ring wraparound at offset 0. The test case that
reproduces the bug reliably forces a large number of interrupted context
switches, thereby causing very frequent ring wraparounds, but there are
similar bug reports in the wild with the same symptoms, seqno writes
stop just before the wrap and the ringbuffer at address 0. It is also
timing crucial, but adding various delays hasn't helped pinpoint where
the window lies.

Whether the fault is restricted to the ringbuffer itself or the GTT
addressing is unclear, but moving the ringbuffer fixes all the hangs I
have been able to reproduce.

References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262
Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1
Signed-off-by: Chris Wilson 
Cc: stable@vger.kernel.org
Acked-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-12-git-send-email-chris@chris-wilson.co.uk
(cherry picked from commit a687a43a48f0f91ba37dce5a14b467258ed6f035)
Signed-off-by: Jani Nikula

drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs

2016-04-18T09:35:50+00:00

Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa)
suggest that WaForceContextSaveRestoreNonCoherent is needed for all
revs. Extending this to all revs cures a gpu hang with rev 0xa when
running heaven4.0 gpu benchmark.

We have been here before, with problems enabling gt4e and extending
up to revision F0 instead of false claims of bspec of E0 only. See
commit  ("drm/i915/skl: Default to noncoherent access
up to F0"). In retrospect we should have covered this with this big
blanket back then already, as E0 vs F0 discrepancy was suspicious
enough.

Previously the WaForceEnableNonCoherent has been tied to
context non-coherence, atleast in relevant hsds. So keep this tie
and extended this alongside.

Cc: Abdiel Janulgue 
Cc: Ben Widawsky 
Cc: Timo Aaltonen 
Cc: stable@vger.kernel.org
Reported-by: Mike Lothian 
References: https://bugs.freedesktop.org/show_bug.cgi?id=93491
Signed-off-by: Mika Kuoppala 
Reviewed-by: Ben Widawsky 
Tested-by: Timo Aaltonen 
Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-2-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 97ea6be161c55dec896b65c95157d953c330ae05)
Signed-off-by: Jani Nikula

drm/i915: Fixup the free space logic in ring_prepare

2016-04-18T09:35:49+00:00

Currently for the case where there is enough space at the end of Ring
buffer for accommodating only the base request, the wrapround is done
immediately and as a result the base request gets added at the start
of Ring buffer. But there may not be enough free space at the beginning
to accommodate the base request, as before the wraparound, the wait was
effectively done for the reserved_size free space from the start of
Ring buffer. In such a case there is a potential of Ring buffer overflow,
the instructions at the head of Ring (ACTHD) can get overwritten.

Since the base request can fit in the remaining space, there is no need
to wraparound immediately. The wraparound will anyway happen later when
the reserved part starts getting used.

Cc: Chris Wilson 
Signed-off-by: Akash Goel 
Signed-off-by: Chris Wilson 
Link: http://patchwork.freedesktop.org/patch/msgid/1457688402-10411-1-git-send-email-akash.goel@intel.com
Reviewed-by: Chris Wilson 
Cc: stable@vger.kernel.org
(cherry picked from commit 782f6bc0aba037436d6a04d19b23f8b61020a576)
Signed-off-by: Jani Nikula

drm/i915: Don't ERROR for an expected intel_rcs_ctx_init() interruption

2016-02-15T09:48:08+00:00

intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
upon a full ring to advance). Don't emit an error for this.

Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1454086145-16160-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

2016-02-11T05:57:32+00:00

While running some tests on the scheduler patches with rpm enabled I
came across a corruption in the ringbuffer, which was root-caused to
the GPU being suspended while commands were being emitted to the
ringbuffer. The access to memory was failing because the GPU needs to
be awake when accessing stolen memory (where my ringbuffer was located).
Since we have this constraint it looks like a sensible idea to check
that we hold a refcount when we access the rungbuffer.

v2: move the check from ring_begin to ringbuffer iomap time (Chris)
v3: update comment (Chris)

Cc: John Harrison 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1453909429-11024-1-git-send-email-daniele.ceraolospurio@intel.com

drm/i915/gen9: Add WaOCLCoherentLineFlush

2016-01-25T15:49:15+00:00

This is mainly required for future enabling of pre-emptive
command execution.

v2: explain purpose of change (Chris)

Reviewed-by: Nick Hoath 
Cc: Dave Gordon 
Signed-off-by: Arun Siluvery 
Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-9-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter

drm/i915/skl: Enable Per context Preemption granularity control

2016-01-25T15:48:52+00:00

Per context preemption granularity control is only available from SKL:E0+

Actual WA is to disable percontext preemption granularity control until D0
which is the default case so this is equivalent to the inverse of
WaDisablePerCtxtPreemptionGranularityControl:skl

v2: add some detail to commit msg (Chris)

Reviewed-by: Nick Hoath 
Cc: Dave Gordon 
Signed-off-by: Arun Siluvery 
Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-8-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter

drm/i915/skl: Add GEN8_L3SQCREG4 to HW whitelist

2016-01-25T15:48:43+00:00

Required for WaDisableLSQCROPERFforOCL:skl

This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.

v2: explain purpose of changes (Chris)

Reviewed-by: Nick Hoath 
Signed-off-by: Arun Siluvery 
Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-7-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter

drm/i915/bxt: Add GEN8_L3SQCREG4 to HW whitelist

2016-01-25T15:48:35+00:00

Required for WaDisableLSQCROPERFforOCL:bxt

According to WA database these are only applicable for BXT:A0 but since
A0 and A1 shares the same GT these are extended for A1 as well.

This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.

v2: explain purpose of changes (Chris)

Reviewed-by: Nick Hoath 
Signed-off-by: Arun Siluvery 
Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-6-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter

drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist

2016-01-25T15:48:28+00:00

Required for,
WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt
WaDisableObjectLevelPreemptionForInstancedDraw:bxt
WaDisableObjectLevelPreemtionForInstanceId:bxt

According to WA database these are only applicable for BXT:A0 but since
A0 and A1 shares the same GT these are extended for A1 as well.

These are also required for SKL until B0 but not adding them because they
are pre-production steppings.

This register is added to HW whitelist to support WA required for future
enabling of pre-emptive command execution, WA implementation will be in
userspace and it cannot program this register if it is not on HW whitelist.

v2: use lower case in register defines (Nick)
v3: explain purpose of changes (Chris)

Reviewed-by: Nick Hoath 
Signed-off-by: Arun Siluvery 
Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-5-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter