[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