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@xxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxx> > > 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... -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
