On Tue, Jul 29, 2014 at 12:26:36PM +0200, Daniel Vetter wrote: > On Tue, Jul 29, 2014 at 08:37:48AM +0100, Chris Wilson wrote: > > On Mon, Jul 28, 2014 at 10:54:06AM +0200, Daniel Vetter wrote: > > > On Sat, Jul 26, 2014 at 11:27:38AM +0100, Chris Wilson wrote: > > > > On Wed, Jun 18, 2014 at 10:54:13PM +0200, Daniel Vetter wrote: > > > > > On Fri, Jun 13, 2014 at 04:38:03PM +0100, oscar.mateo@xxxxxxxxx wrote: > > > > > > From: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > > > > > > > > > > Or with a spinlock grabbed, because it might sleep, which is not > > > > > > a nice thing to do. Instead, do the runtime_pm get/put together > > > > > > with the create/destroy request, and handle the forcewake get/put > > > > > > directly. > > > > > > > > > > > > Signed-off-by: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > > > > > > > > Looks like a fixup that should be squashed into relevant earlier patches. > > > > > > > > The whole gen6_gt_force_wake_get() calling intel_runtime_pm_get() is > > > > broken due to this - we must be able to read registers in atomic > > > > context! > > > > > > > > Please revert c8c8fb33b37766acf6474784b0d5245dab9a1690 > > > > > > force_wake_get can't call runtime_pm_get becuase pm_get can sleep. So if > > > you want to read registers from atomic context you have to have a runtime > > > pm reference from someone else. > > > > Nope. That cannot work. > > Well it works currently. So where do you see the problem? Sampling registers from an timer - in particular, we really do not want to disable runtime pm whilst trying to monitor the impact of runtime pm. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
