From 8d4bf1ce648ab1b16eca14baf778cc39756afbeb Mon Sep 17 00:00:00 2001 From: Cyril Brulebois Date: Sat, 15 Dec 2018 16:34:38 +0100 Subject: [PATCH] Revert "drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit 06e562e7f515292ea7721475950f23554214adde. v4.18.20 regresses at least on gen4 as seen in these bug reports: https://bugs.freedesktop.org/108850 https://bugs.freedesktop.org/108984 https://bugs.debian.org/914980 https://redmine.tails.boum.org/code/issues/16224 This patch landed in various drm-intel branches but hasn't found its way to linux-4.18.y yet: https://patchwork.freedesktop.org/patch/265653/ Trying to apply it on top of v4.18.20 triggers several conflicts, so it seems safer to just revert what seems to be the culprit, as confirmed by a user reporting this revert fixes the problem for them, and by this part of the commit message for the actual fix in drm-intel: commit 5179749925933575a67f9d8f16d0cc204f98a29f Author: Chris Wilson Date: Tue Dec 4 14:15:16 2018 +0000 drm/i915: Allocate a common scratch page [กฤ] Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850 [กฤ] Signed-off-by: Cyril Brulebois --- drivers/gpu/drm/i915/intel_ringbuffer.c | 38 ++------------------------------- 1 file changed, 2 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 72007d634359..8f19349a6055 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -91,7 +91,6 @@ static int gen4_render_ring_flush(struct i915_request *rq, u32 mode) { u32 cmd, *cs; - int i; /* * read/write caches: @@ -128,45 +127,12 @@ gen4_render_ring_flush(struct i915_request *rq, u32 mode) cmd |= MI_INVALIDATE_ISP; } - i = 2; - if (mode & EMIT_INVALIDATE) - i += 20; - - cs = intel_ring_begin(rq, i); + cs = intel_ring_begin(rq, 2); if (IS_ERR(cs)) return PTR_ERR(cs); *cs++ = cmd; - - /* - * A random delay to let the CS invalidate take effect? Without this - * delay, the GPU relocation path fails as the CS does not see - * the updated contents. Just as important, if we apply the flushes - * to the EMIT_FLUSH branch (i.e. immediately after the relocation - * write and before the invalidate on the next batch), the relocations - * still fail. This implies that is a delay following invalidation - * that is required to reset the caches as opposed to a delay to - * ensure the memory is written. - */ - if (mode & EMIT_INVALIDATE) { - *cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE; - *cs++ = i915_ggtt_offset(rq->engine->scratch) | - PIPE_CONTROL_GLOBAL_GTT; - *cs++ = 0; - *cs++ = 0; - - for (i = 0; i < 12; i++) - *cs++ = MI_FLUSH; - - *cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE; - *cs++ = i915_ggtt_offset(rq->engine->scratch) | - PIPE_CONTROL_GLOBAL_GTT; - *cs++ = 0; - *cs++ = 0; - } - - *cs++ = cmd; - + *cs++ = MI_NOOP; intel_ring_advance(rq, cs); return 0; -- 2.11.0