[Intel-gfx] [PATCH] drm/i915: Fix runtime pm inbalance due to reg I/O forcewake dance

Ville Syrjälä ville.syrjala at linux.intel.com
Fri Mar 14 09:34:36 CET 2014


On Fri, Mar 14, 2014 at 08:24:00AM +0000, Chris Wilson wrote:
> On Fri, Mar 14, 2014 at 10:18:47AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 14, 2014 at 08:48:46AM +0100, Daniel Vetter wrote:
> > > This regression has been introduced in
> > > 
> > > commit 8232644ccf099548710843e97360a3fcd6d28e04
> > > Author: Chris Wilson <chris at chris-wilson.co.uk>
> > > Date:   Wed Mar 5 12:00:39 2014 +0000
> > > 
> > >     drm/i915: Convert the forcewake worker into a timer func
> > > 
> > > which started to use the delayed forcewake put also for the register
> > > I/O forcewake dance. But this conflicts functionally with the
> > > (reviewed in parallel)
> > > 
> > > commit 6d88064edcfc5e5893371f7c06b9f3078dc1edf6
> > > Author: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > > Date:   Fri Feb 21 17:58:29 2014 -0300
> > > 
> > >     drm/i915: put runtime PM only when we actually release force_wake
> > > 
> > > which moved the runtime pm put calls into the delayed forcewake put
> > > function to avoid an inversion between these. The problem is that the
> > > register I/O function do _not_ grab a runtime pm reference, hence
> > > dropping it is a bug.
> > > 
> > > So split the timer into two to re-balance the runtime pm refcounting.
> > > The tricky bit to ensure is that the _raw timer doesn't run after
> > > we've runtime-suspended the device. After all it only has an implicit
> > > runtime pm reference provided by its caller. But the del_timer_sync in
> > > the runtime suspend code will ensure this.
> > > 
> > > Add a comment to document this all.
> > 
> > Yuck. Why don't we just stick the runtime pm put into
> > gen6_gt_force_wake_put() and let Chris's timer cancellation +
> > forcewake reset fixes take care of things?
> 
> Heh, I went the other way round, dropped the runtime pm put from the
> timer and flushed the forcewaker timer when we suspended the device...

That's what I meant. No delayed runtime_pm_put.

-- 
Ville Syrjälä
Intel OTC



More information about the Intel-gfx mailing list