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