[PATCH 3/3] drm/i915: Avoid using MI_STORE_DWORD_IMM on vecs

[Chris Wilson]

It turns out that our MI_FLUSH_DW we perform after each batch is not
sufficient to flush MI_STORE_DWORD_IMM to memory. Of course, this raises
the concern that MI_FLUSH_DW may not be flushing anything on vecs, but
for the moment we have to neuter our own use of store-dw.

I have tried:

	8x MI_FLUSH_DW (with post-op sync)
	8x MI_STORE_DWORD_IMM
	8x MI_STORE_REG_MEM + MI_LOAD_REG_MEM

with no lasting effect; they only appear to add some extra delay on the
flush which partially masks the issue but not solve it.

Testcase: igt/i915_selftest/live_coherency
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index 759c0fd58f8c..117667cfbda1 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1195,10 +1195,14 @@ bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
 	case 3:
 		/* maybe only uses physical not virtual addresses */
 		return !(IS_I915G(engine->i915) || IS_I915GM(engine->i915));
+	case 4:
+	case 5:
+		/* no known limitations */
+		return true;
 	case 6:
 		return engine->class != VIDEO_DECODE_CLASS; /* b0rked */
 	default:
-		return true;
+		return engine->class != VIDEO_ENHANCEMENT_CLASS;/* incoherent */
 	}
 }
 
-- 
2.19.1