[Intel-gfx] [PATCH v2] drm/i915: avoid processing spurious/shared interrupts in low-power states

Chris Wilson chris at chris-wilson.co.uk
Mon Feb 23 03:57:04 PST 2015


On Mon, Feb 23, 2015 at 11:58:14AM +0200, Imre Deak wrote:
> Atm, it's possible that the interrupt handler is called when the device
> is in D3 or some other low-power state. It can be due to another device
> that is still in D0 state and shares the interrupt line with i915, or on
> some platforms there could be spurious interrupts even without sharing
> the interrupt line. The latter case was reported by Klaus Ethgen using a
> Lenovo x61p machine (gen 4). He noticed this issue via a system
> suspend/resume hang and bisected it to the following commit:
> 
> commit e11aa362308f5de467ce355a2a2471321b15a35c
> Author: Jesse Barnes <jbarnes at virtuousgeek.org>
> Date:   Wed Jun 18 09:52:55 2014 -0700
> 
>     drm/i915: use runtime irq suspend/resume in freeze/thaw
> 
> This is a problem, since in low-power states IIR will always read
> 0xffffffff resulting in an endless IRQ servicing loop.
> 
> Fix this by handling interrupts only when the driver explicitly enables
> them and so it's guaranteed that the interrupt registers return a valid
> value.
> 
> Note that this issue existed even before the above commit, since during
> runtime suspend/resume we never unregistered the handler.
> 
> v2:
> - clarify the purpose of smp_mb() vs. synchronize_irq() in the
>   code comment(Chris)
> 
> Reference: https://lkml.org/lkml/2015/2/11/205
> Reported-and-bisected-by: Klaus Ethgen <Klaus at Ethgen.ch>
> Signed-off-by: Imre Deak <imre.deak at intel.com>

Thanks! That comment makes it very clear.
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list