[PATCH] drm/i915: forcewake fix after reset

[PATCH] drm/i915: forcewake fix after reset

[Ben Widawsky]

The failure is as follows:

1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect

The failure can only occur when using the forcewake userspace lock.

This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.

The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_drv.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..609358f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -579,6 +579,9 @@ int i915_reset(struct drm_device *dev, u8 flags)
 	} else switch (INTEL_INFO(dev)->gen) {
 	case 6:
 		ret = gen6_do_reset(dev, flags);
+		/* If reset with a user forcewake, try to restore */
+		if (atomic_read(&dev_priv->forcewake_count))
+			__gen6_gt_force_wake_get(dev_priv);
 		break;
 	case 5:
 		ret = ironlake_do_reset(dev, flags);
-- 
1.7.5.2

Re: [PATCH] drm/i915: forcewake fix after reset

[Chris Wilson]

On Fri, 24 Jun 2011 14:31:47 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> The failure is as follows:
> 
> 1. Userspace gets forcewake lock, lock count >=1
> 2. GPU hang/reset occurs (forcewake bit is reset)
> 3. count is now incorrect
> 
> The failure can only occur when using the forcewake userspace lock.
> 
> This has the unfortunate consequence of messing up the driver as well as
> userspace, unless userspace closes the debugfs file, the kernel will
> never end up waking the GT since the refcount will be > 1.
> 
> The solution is to try to recover the correct forcewake state based on
> the refcount. There is a period of time where userspace reads/writes may
> occur after the reset, before the GT has been forcewaked. The interface
> was never designed to be a perfect solution for userspace reads/writes,
> and the kernel portion is fixed by this patch.
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Excellent change log.

My only quibble is that we should do this as gen6_post_reset(), but that
can be done when we more tasks to perform after reseting the GPU on
different generations.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre