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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
