On 2019-09-26 16:24:59 [+0100], Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > > > index bc83f094065a..f3df7714a3f3 100644 > > > --- a/drivers/gpu/drm/i915/i915_irq.c > > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private *dev_priv) > > > > > > intel_irq_reset(dev_priv); > > > > > > - ret = request_irq(irq, intel_irq_handler(dev_priv), > > > - IRQF_SHARED, DRIVER_NAME, dev_priv); > > > + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv), > > > + IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will > > keep interrupting the CPU and you never manage to switch to the thread. > > The interrupts only keep coming if we feed the GPU, and we only feed the > GPU if we service the interrupt. That should provide a natural > quiescence :) In IRQ-context your primary handler gets invoked which wakes the thread (what ever intel_irq_handler() returns). Then you leave the IRQ context and should switch to your IRQ-handler. This will never happen because the IRQ line remains asserted and CPU ends up in the primary handler again. An EDGE typed IRQ wouldn't notice a difference. But a LINE typed IRQ will remain asserted until the hardware de-asserts the interrupt again. Since you never reach your thread handler, I don't see how this can happen. > -Chris Sebastian _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
