[PATCH 5/5] noreq

Chris Wilson chris at chris-wilson.co.uk
Sat Jul 14 13:55:32 UTC 2018


---
 drivers/gpu/drm/i915/i915_gem.c | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 42d24410a98c..2c45ae226b1f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3224,25 +3224,6 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
 		ce = fetch_and_zero(&engine->last_retired_context);
 		if (ce)
 			intel_context_unpin(ce);
-
-		/*
-		 * Ostensibily, we always want a context loaded for powersaving,
-		 * so if the engine is idle after the reset, send a request
-		 * to load our scratch kernel_context.
-		 *
-		 * More mysteriously, if we leave the engine idle after a reset,
-		 * the next userspace batch may hang, with what appears to be
-		 * an incoherent read by the CS (presumably stale TLB). An
-		 * empty request appears sufficient to paper over the glitch.
-		 */
-		if (intel_engine_is_idle(engine)) {
-			struct i915_request *rq;
-
-			rq = i915_request_alloc(engine,
-						dev_priv->kernel_context);
-			if (!IS_ERR(rq))
-				i915_request_add(rq);
-		}
 	}
 
 	i915_gem_restore_fences(dev_priv);
-- 
2.18.0



More information about the Intel-gfx-trybot mailing list