On Mon, 18 Apr 2011 10:31:43 -0700, Ben Widawsky wrote:
> gen6_gt_force_wake_get()
> while(foo)
> i915_read32_awake()
> gen6_gt_force_wake_put()
Uh. Anything looping on registers might not want to hold the lock...
--
keith.pack...@intel.com
pgpgKFMx6v8mp.pgp
Description: PGP signature
On Mon, 18 Apr 2011 10:31:43 -0700, Ben Widawsky wrote:
> I'll split the patches. I can also use the awake() variant for the
> existing users, if you're okay with the awake() function (I was actually
> expecting a comment from you on that). For the relevant functions, it
> should be as simple as:
On Sat, Apr 16, 2011 at 07:52:44AM +0100, Chris Wilson wrote:
> On Thu, 14 Apr 2011 11:13:46 -0700, Ben Widawsky wrote:
> > Provide a reference count to track the forcewake state of the GPU. The
> > savings is up to 1 UC read if the unit is already awake, but the main
> > goal is to give userspace
On Thu, 14 Apr 2011 11:13:46 -0700, Ben Widawsky wrote:
> Provide a reference count to track the forcewake state of the GPU. The
> savings is up to 1 UC read if the unit is already awake, but the main
> goal is to give userspace some mechanism to wake the GPU.
>
> v2:
> Added a spin_lock for sync
Provide a reference count to track the forcewake state of the GPU. The
savings is up to 1 UC read if the unit is already awake, but the main
goal is to give userspace some mechanism to wake the GPU.
v2:
Added a spin_lock for synchronizing access to forcewake. The lock
should not be heavily contest
Provide a reference count to track the forcewake state of the GPU. The
savings is up to 1 UC read if the unit is already awake, but the main
goal is to give userspace some mechanism to wake the GPU.
v2:
Added a spin_lock for synchronizing access to forcewake. The lock
should not be heavily contest
