With the two-step reset counter increments which braket the actual
reset code and the subsequent wake-up we're guaranteeing that all the
lockless waiters _will_ be woken up. And since we unconditionally bail
out of waits with -EAGAIN (or -EIO) in that case there is not risk of
lost interrupt enabling bits when the lockless wait code races against
a gpu reset.
Let's remove this FIXME as resolved then.
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
drivers/gpu/drm/i915/i915_drv.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc6c51107047..89741e6e2d08 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -878,12 +878,6 @@ int i915_reset(struct drm_device *dev)
}
/*
- * FIXME: This races pretty badly against concurrent holders of
- * ring interrupts. This is possible since we've started to drop
- * dev->struct_mutex in select places when waiting for the gpu.
- */
-
- /*
* rps/rc6 re-init is necessary to restore state lost after the
* reset and the re-install of gt irqs. Skip for ironlake per
* previous concerns that it doesn't respond well to some forms
--
2.1.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
