A long time ago, we were afraid of handling interrupts and signaling
waiters during a reset, worrying that the confusion in request handling
would interfere with our attempts to process the reset in an orderly
fashion. Since then, we have isolated our irq-driven request handling by
virtual of the engine->timeline.lock and control of kthreads where
required, eliminating the danger of concurrently processing interrupts.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@intel.com>
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 64e0ea4bef67..e65ef733f991 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1918,7 +1918,6 @@ void i915_reset(struct drm_i915_private *i915,
dev_notice(i915->drm.dev, "Resetting chip for %s\n", reason);
error->reset_count++;
- disable_irq(i915->drm.irq);
ret = i915_gem_reset_prepare(i915);
if (ret) {
dev_err(i915->drm.dev, "GPU recovery failed\n");
@@ -1980,8 +1979,6 @@ void i915_reset(struct drm_i915_private *i915,
finish:
i915_gem_reset_finish(i915);
- enable_irq(i915->drm.irq);
-
wakeup:
clear_bit(I915_RESET_HANDOFF, &error->flags);
wake_up_bit(&error->flags, I915_RESET_HANDOFF);
--
2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
