[Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings

[Imre Deak]

Due to a coherency issue on BXT A steppings we can't guarantee a
coherent view of cached GPU mappings, so fall back to uncached mappings.
Note that this still won't fix cases where userspace expects a coherent
view without synchronizing (via a set domain call). It still makes sense
to limit the kernel's notion of the mapping to be uncached, for example
for relocations to work properly during execbuffer time. Also in case
user space does synchronize the buffer, this will still guarantee that
we'll do the proper clflushing for the buffer.

v2:
- limit the WA to A steppings, on later stepping this HW issue is fixed

Testcast: igt/gem_store_dword_batches_loop/cached-mapping
Signed-off-by: Imre Deak <imre.deak at intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 407b6b3..987ffa8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3742,7 +3742,16 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
 		level = I915_CACHE_NONE;
 		break;
 	case I915_CACHING_CACHED:
-		level = I915_CACHE_LLC;
+		/*
+		 * Due to a HW issue on BXT A stepping, GPU stores via a
+		 * snooped mapping may leave stale data in a corresponding CPU
+		 * cacheline, whereas normally such cachelines would get
+		 * invalidated. As a workaround assume that these stores are
+		 * not coherent, which means we'll flush the CPU cache manually
+		 * whenever doing a CPU/GPU sync operation.
+		 */
+		level = IS_BROXTON(dev) && INTEL_REVID(dev) < BXT_REVID_B0 ?
+			I915_CACHE_NONE : I915_CACHE_LLC;
 		break;
 	case I915_CACHING_DISPLAY:
 		level = HAS_WT(dev) ? I915_CACHE_WT : I915_CACHE_NONE;
-- 
2.1.4