[RFC 05/10] drm/i915: Pull out user PAT checks

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

At a few strategic call sites it is easier to understand what is going on
if obj->pat_set_by_user checks are pulled out from
i915_gem_object_has_cache_level into the callers.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Cc: Matt Roper <matthew.d.roper at intel.com>
Cc: Fei Yang <fei.yang at intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c     | 13 ++++++++-----
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  7 +++----
 drivers/gpu/drm/i915/gem/i915_gem_mman.c       | 11 ++++-------
 3 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 57db9c581bf6..d9578a5ffeba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -41,11 +41,14 @@ static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 		return false;
 
 	/*
-	 * For objects created by userspace through GEM_CREATE with pat_index
-	 * set by set_pat extension, i915_gem_object_has_cache_level() will
-	 * always return true, because the coherency of such object is managed
-	 * by userspace. Othereise the call here would fall back to checking
-	 * whether the object is un-cached or write-through.
+	 * Never flush cache for UMD objects with PAT index set.
+	 */
+	if (obj->pat_set_by_user)
+		return false;
+
+	/*
+	 * Fully coherent cached access may end up with data in the CPU cache
+	 * which hasn't hit memory yet.
 	 */
 	return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
 		 i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 0a1d40220020..0461bdba2bd4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -642,13 +642,12 @@ static inline int use_cpu_reloc(const struct reloc_cache *cache,
 
 	/*
 	 * For objects created by userspace through GEM_CREATE with pat_index
-	 * set by set_pat extension, i915_gem_object_has_cache_level() always
-	 * return true, otherwise the call would fall back to checking whether
-	 * the object is un-cached.
+	 * set by set_pat extension we don't know the caching mode so assume no.
 	 */
 	return (cache->has_llc ||
 		obj->cache_dirty ||
-		!i915_gem_object_has_cache_level(obj, I915_CACHE_NONE));
+		(!obj->pat_set_by_user &&
+		 !i915_gem_object_has_cache_level(obj, I915_CACHE_NONE)));
 }
 
 static int eb_reserve_vma(struct i915_execbuffer *eb,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index aa4d842d4c5a..32bc4ddc92e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -385,14 +385,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
 	/* Access to snoopable pages through the GTT is incoherent. */
 	/*
 	 * For objects created by userspace through GEM_CREATE with pat_index
-	 * set by set_pat extension, coherency is managed by userspace, make
-	 * sure we don't fail handling the vm fault by calling
-	 * i915_gem_object_has_cache_level() which always return true for such
-	 * objects. Otherwise this helper function would fall back to checking
-	 * whether the object is un-cached.
+	 * set by set_pat extension caching mode is unknown so assume the worst.
 	 */
-	if (!(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
-	      HAS_LLC(i915))) {
+	if (!HAS_LLC(i915) &&
+	    (obj->pat_set_by_user ||
+	     !i915_gem_object_has_cache_level(obj, I915_CACHE_NONE))) {
 		ret = -EFAULT;
 		goto err_unpin;
 	}
-- 
2.39.2