Re: [PATCH] drm/i915: synchronize_irq() against the actual irq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxxxxx>
> > Reported-by: Imre Deak <imre.deak@xxxxxxxxx>
> > 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@xxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxxxxx>
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux