[Intel-gfx] [PATCH] drm/i915: rip out the PM_IIR WARN

[Daniel Vetter]

On Thu, Jun 21, 2012 at 02:55:22PM +0200, Daniel Vetter wrote:
> After banging my head against this for the past few months, I still
> don't see how this could possible race under the premise that once an
> irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
> until we unmask it in PM_IMR.
> 
> Still, we have reports of this being seen in the wild. Now Bspec has
> this little bit of lovely language in the PMIIR register:
> 
> Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
> 
> "For each bit, the IIR can store a second pending interrupt if two or
> more of the same interrupt conditions occur before the first condition
> is cleared. Upon clearing the interrupt, the IIR bit will momentarily
> go low, then return high to indicate there is another interrupt
> pending."
> 
> Now if we presume that PMIMR only prevent new interrupts from being
> queued, we could easily end up masking an interrupt and clearing it,
> but the 2nd pending interrupt setting the bit in PMIIR right away
> again. Which leads, the next time the irq handler runs, to hitting the
> WARN.
> 
> Also, no bad side effects of this have ever been reported. And we've
> tracked down our issues with the gpu turbo getting stuck to bogus
> interrupt generation limits in th RPLIMIT register.
> 
> So let's just rip out this WARN as bogus and call it a day. The only
> shallow thing here is that this 2-deep irq queue in the hw makes you
> wonder how racy the windows irq handler is ...
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
> Cc: stable at vger.kernel.org
> Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
I've picked this one up for -fixes.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48