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

[Chris Wilson]

On Thu, 21 Jun 2012 14:55:22 +0200, Daniel Vetter <daniel.vetter at ffwll.ch> 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.

Ok, if we suppose that the PMIMR is only applied when the interrupt is
asserted in the double-buffered register rather than on transfer of that
backing register into PMIIR, I can see how that would lead to hitting
the WARN as you outlined.
 
> 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.

True, our current usage is simply to poke the rps up/down, and so if we
miss an interrupt we simply get another one a few milliseconds later
(presumably) in the same direction.
 
> 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>
Acked-by: Chris Wilson <chris at chris-wilson.co.uk>

If we cared we could request a BUN to clarify when the mask is applied.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre