Chris Wilson <[email protected]> writes: > Haswell also requires the RING_IMR flush for its unique vebox setup to > avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush > RING_IMR changes before changing the global GT IMR"): > > On Baytail, notably, we can still detect missed interrupt syndrome > (where we never spot a completed request). In this case, it can be > alleviated by always keeping the interrupt unmasked, implying that the > interrupt is being lost in the window after modifying the IMR. (This is > the reason we still have the posting reads on enable_irq, if we remove > them we miss interrupts!) Having narrowed the issue down to the IMR, > rather than keeping it always enabled, applying the usual posting > read/flush of the RING_IMR before unmasking the GT IMR also seems to > prevent the missed interrupt. So be it. > > References: 476af9c26063 ("drm/i915/gen6: Flush RING_IMR changes before > changing the global GT IMR") > Signed-off-by: Chris Wilson <[email protected]> > Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]> > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 3d5d6b908148..6e2661e86d18 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -996,6 +996,10 @@ hsw_vebox_irq_enable(struct intel_engine_cs *engine) > struct drm_i915_private *dev_priv = engine->i915; > > I915_WRITE_IMR(engine, ~engine->irq_enable_mask); > + > + /* Flush/delay to ensure the RING_IMR is active before the GT IMR */ > + POSTING_READ_FW(RING_IMR(engine->mmio_base)); > + > gen6_unmask_pm_irq(dev_priv, engine->irq_enable_mask); > } > > -- > 2.20.1 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
