drm/xe/bo: reduce xe_bo_create_pin_map() restrictions
authorMatthew Auld <matthew.auld@intel.com>
Fri, 20 Jan 2023 11:48:53 +0000 (11:48 +0000)
committerRodrigo Vivi <rodrigo.vivi@intel.com>
Tue, 19 Dec 2023 23:27:44 +0000 (18:27 -0500)
commitf3edf6917ca8e4e11a6af39e926558d4609dd9ea
treec2a03d8f7e0f74ec79627a86f1f570866a28afd7
parent9b6483af3709386fe0e544bfa8cc01f8a92e0d57
drm/xe/bo: reduce xe_bo_create_pin_map() restrictions

On DGFX this blows up if can call this with a system memory object:

XE_BUG_ON(!mem_type_is_vram(place->mem_type) && place->mem_type != XE_PL_STOLEN);

If we consider dpt it looks like we can already in theory hit this, if
we run out of vram and stolen vram. It at least seems reasonable to
allow calling this on any object which supports CPU access.

Note this also changes the behaviour with stolen VRAM and suspend, such
that we no longer attempt to migrate stolen objects into system memory.
However nothing in stolen should ever need to be restored (same on
integrated), so should be fine. Also on small-bar systems the stolen
portion is pretty much always non-CPU accessible, and currently pinned
objects use plain memcpy when being moved, which doesn't play nicely.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drivers/gpu/drm/xe/xe_bo.c