Commit 9153e6b7 authored by Chris Wilson's avatar Chris Wilson

drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 767a983a ("drm/i915/execlists: Read the context-status HEAD
from the HWSP") those uncached reads were eliminated (on one path at
least) and along with them our serialisation. The result is that we
would very rarely miss notification of a new interrupt and leave a
context-switch unprocessed, hanging the GPU.

Fixes: 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk
parent d871bfd0
...@@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long data) ...@@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long data)
struct drm_i915_private *dev_priv = engine->i915; struct drm_i915_private *dev_priv = engine->i915;
bool fw = false; bool fw = false;
/* We can skip acquiring intel_runtime_pm_get() here as it was taken /*
* We can skip acquiring intel_runtime_pm_get() here as it was taken
* on our behalf by the request (see i915_gem_mark_busy()) and it will * on our behalf by the request (see i915_gem_mark_busy()) and it will
* not be relinquished until the device is idle (see * not be relinquished until the device is idle (see
* i915_gem_idle_work_handler()). As a precaution, we make sure * i915_gem_idle_work_handler()). As a precaution, we make sure
...@@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long data) ...@@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long data)
*/ */
GEM_BUG_ON(!dev_priv->gt.awake); GEM_BUG_ON(!dev_priv->gt.awake);
/* Prefer doing test_and_clear_bit() as a two stage operation to avoid /*
* Prefer doing test_and_clear_bit() as a two stage operation to avoid
* imposing the cost of a locked atomic transaction when submitting a * imposing the cost of a locked atomic transaction when submitting a
* new request (outside of the context-switch interrupt). * new request (outside of the context-switch interrupt).
*/ */
...@@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned long data) ...@@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned long data)
execlists->csb_head = -1; /* force mmio read of CSB ptrs */ execlists->csb_head = -1; /* force mmio read of CSB ptrs */
} }
/* The write will be ordered by the uncached read (itself /* Clear before reading to catch new interrupts */
* a memory barrier), so we do not need another in the form clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
* of a locked instruction. The race between the interrupt smp_mb__after_atomic();
* handler and the split test/clear is harmless as we order
* our clear before the CSB read. If the interrupt arrived
* first between the test and the clear, we read the updated
* CSB and clear the bit. If the interrupt arrives as we read
* the CSB or later (i.e. after we had cleared the bit) the bit
* is set and we do a new loop.
*/
__clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
if (unlikely(execlists->csb_head == -1)) { /* following a reset */ if (unlikely(execlists->csb_head == -1)) { /* following a reset */
if (!fw) { if (!fw) {
intel_uncore_forcewake_get(dev_priv, intel_uncore_forcewake_get(dev_priv,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment