Commit 0aeec60c authored by Niranjana Vishwanathapura's avatar Niranjana Vishwanathapura Committed by Andi Shyti
Browse files

drm/i915: Do not set cache_dirty for DGFX 



Currently on DG1, which does not have LLC, we hit the below
warning while rebinding an userptr invalidated object.

WARNING: CPU: 4 PID: 13008 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 __i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
Call Trace:
 <TASK>
 i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
 ____i915_gem_object_get_pages+0x32/0xb0 [i915]
 i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
 eb_lookup_vmas+0x2ff/0xcf0 [i915]
 ? __intel_wakeref_get_first+0x55/0xb0 [i915]
 i915_gem_do_execbuffer+0x785/0x21d0 [i915]
 i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]

We shouldn't be setting the obj->cache_dirty for DGFX,
fix it.

Fixes: d70af579 ("drm/i915/shmem: ensure flush during swap-in on non-LLC")
Suggested-by: default avatarMatthew Auld <matthew.auld@intel.com>
Reported-by: default avatarNiranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: default avatarNiranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Acked-by: default avatarNirmoy Das <nirmoy.das@intel.com>
Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
Reviewed-by: default avatarAndi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: default avatarAndi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102051416.27327-1-niranjana.vishwanathapura@intel.com
parent 1086af67

drivers/gpu/drm/i915/gem/i915_gem_shmem.c

+2 −2
Original line number Diff line number Diff line
@@ -369,14 +369,14 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj, 


	__start_cpu_write(obj);

	/*

	 * On non-LLC platforms, force the flush-on-acquire if this is ever

	 * On non-LLC igfx platforms, force the flush-on-acquire if this is ever

	 * swapped-in. Our async flush path is not trust worthy enough yet(and

	 * happens in the wrong order), and with some tricks it's conceivable

	 * for userspace to change the cache-level to I915_CACHE_NONE after the

	 * pages are swapped-in, and since execbuf binds the object before doing

	 * the async flush, we have a race window.

	 */

	if (!HAS_LLC(i915))

	if (!HAS_LLC(i915) && !IS_DGFX(i915))

		obj->cache_dirty = true;

}