Re: [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Feb 02, 2018 at 05:31:57PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-02 16:03:36)
> > On Fri, Feb 02, 2018 at 03:34:48PM +0000, Chris Wilson wrote:
> > > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > > is possible for the master IIR to indicate a pending IRQ for which we
> > > have already cleared from the GTIIR. In this case, the DRM_ERROR are
> > > intended and should not be flagged as an error.
> > 
> > I guess an alternative would be to not clear IIR and use
> > sychronize_irq() instead as needed. But I suppose that doesn't
> > really provide any real benefits.
> > 
> > One concern is that we will now claim that all interrupts are handled,
> > and thus couldn't detect spurious interrupts. But one might hope that
> > MSI and whanot has made those a thing of the past.
> 
> We only say handled if the master IIR holds an interrupt, so not
> entirely lost. At present, we say IRQ_NONE even though the master IIR
> did raise the interrupt which seems wrong.
> 
> > I never checked what the kernel's threshold was for disabling the
> > interrupt line on spurious interrupts. I have occasionally thought about
> > it though as I too have realized that the IIR clearing could result in
> > the interrupt handler having nothing to do.
> > 
> > So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
> > only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
> > always for all MSI capable platforms?
> 
> I think we're okay with just using the master IIR for IRQ_NONE /
> IRQ_HANDLED as that is the interrupt generator aiui. If the child
> sources disagree that's another issue, but as far as the kernel is
> concerned i915 did generate and handle an interrupt.

I think that might be the usual way it goes. I guess the IIR clearing is
racing with the MASTER_IRQ read as AFAIK the MASTER_IRQ status bits aren't
latched or anything (since we don't have to clear them). So I believe this
still leaves open a small window where even the MASTER_IRQ has cleared
itself by the time the irq handler gets around to reading it. So that
would look like a genuine spurious interrupt even though the GPU did
raise it for a reason.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx