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.vetter@xxxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
