[Intel-gfx] [PATCH] drm/i915: synchronize_irq() against the actual irq

Imre Deak imre.deak at intel.com
Tue Jul 2 15:10:13 UTC 2019


On Tue, Jul 02, 2019 at 03:58:46PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-07-02 15:49:47)
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > When eliminating our use of drm_irq_install() I failed to convert
> > all our synchronize_irq() calls to consult pdev->irq instead of
> > dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq
> > we're no longer synchronizing against anything.
> > 
> > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > Reported-by: Imre Deak <imre.deak at intel.com>
> > Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Oops.
> 
> Lots of duplication there, I don't think an
> 
> static inline void intel_synchronize_irq(struct drm_i915_private *i915)
> {
> 	synchronize_irq(i915->drm.pdev->irq);
> }
> 
> (intel_ or i915_ depending on taste)
> 
> would go amiss. Sadly kernel/irq/irqdesc.c doesn't report a bogus irq
> number or else we could have marked the drm.irq as bad.
> 
> Kudos to Imre for figuring out the link as that bug report had been
> worrying me, and never once did I suspect it was the irq serialisation.

The wakeref count tracking gave the clue and then what the common thing
on the path could be for HSW..ICL (probably not irq_reset()!) :)

> 
> All callsites converted,
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> -Chris


More information about the Intel-gfx mailing list