summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_gem.c
diff options
context:
space:
mode:
authorChris Wilson2013-06-12 11:15:12 +0200
committerDaniel Vetter2013-06-16 01:10:45 +0200
commit19b2dbde5732170a03bd82cc8bd442cf88d856f7 (patch)
tree2c3da40ef05cb5b8a48945b877600e39a5d40ca5 /drivers/gpu/drm/i915/i915_gem.c
parentLinux 3.10-rc6 (diff)
downloadkernel-qcow2-linux-19b2dbde5732170a03bd82cc8bd442cf88d856f7.tar.gz
kernel-qcow2-linux-19b2dbde5732170a03bd82cc8bd442cf88d856f7.tar.xz
kernel-qcow2-linux-19b2dbde5732170a03bd82cc8bd442cf88d856f7.zip
drm/i915: Restore fences after resume and GPU resets
Stéphane Marchesin found that fences for pinned objects (i.e. the scanout) were not being restored upon resume, leading to corruption on the display and reference counting issues. This is due to a bug in commit 312817a39f17dbb4de000165b5b724e3728cd91c [2.6.38] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Nov 22 11:50:11 2010 +0000 drm/i915: Only save and restore fences for UMS that zapped the pinned fences even though they were in use. Fortuitously, whilst we forced a VT switch during suspend and resume, no fences were ever pinned at the time. However, we now can do switchless S3 transitions and so the old bug finally surfaces. Reported-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem.c')
-rw-r--r--drivers/gpu/drm/i915/i915_gem.c22
1 files changed, 5 insertions, 17 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 970ad17c99ab..a06974127f22 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2117,25 +2117,15 @@ static void i915_gem_reset_ring_lists(struct drm_i915_private *dev_priv,
}
}
-static void i915_gem_reset_fences(struct drm_device *dev)
+void i915_gem_restore_fences(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i;
for (i = 0; i < dev_priv->num_fence_regs; i++) {
struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
-
- if (reg->obj)
- i915_gem_object_fence_lost(reg->obj);
-
- i915_gem_write_fence(dev, i, NULL);
-
- reg->pin_count = 0;
- reg->obj = NULL;
- INIT_LIST_HEAD(&reg->lru_list);
+ i915_gem_write_fence(dev, i, reg->obj);
}
-
- INIT_LIST_HEAD(&dev_priv->mm.fence_list);
}
void i915_gem_reset(struct drm_device *dev)
@@ -2158,8 +2148,7 @@ void i915_gem_reset(struct drm_device *dev)
obj->base.read_domains &= ~I915_GEM_GPU_DOMAINS;
}
- /* The fence registers are invalidated so clear them out */
- i915_gem_reset_fences(dev);
+ i915_gem_restore_fences(dev);
}
/**
@@ -3865,8 +3854,6 @@ i915_gem_idle(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
- i915_gem_reset_fences(dev);
-
/* Hack! Don't let anybody do execbuf while we don't control the chip.
* We need to replace this with a semaphore, or something.
* And not confound mm.suspended!
@@ -4193,7 +4180,8 @@ i915_gem_load(struct drm_device *dev)
dev_priv->num_fence_regs = 8;
/* Initialize fence registers to zero */
- i915_gem_reset_fences(dev);
+ INIT_LIST_HEAD(&dev_priv->mm.fence_list);
+ i915_gem_restore_fences(dev);
i915_gem_detect_bit_6_swizzle(dev);
init_waitqueue_head(&dev_priv->pending_flip_queue);