summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/tegra/sor.h
diff options
context:
space:
mode:
authorMatthew Auld <matthew.auld@intel.com>2023-02-08 17:53:16 +0300
committerChristian König <christian.koenig@amd.com>2023-02-23 12:29:00 +0300
commitc604d31950d10db45267bbcb9ce8f1dbc2bfa74e (patch)
tree39a1ededd9f44c537d03bf8310f1267df34a050f /drivers/gpu/drm/tegra/sor.h
parent4d5a2cce47a8e1e7119a881a4714f0eee557c1cd (diff)
downloadlinux-c604d31950d10db45267bbcb9ce8f1dbc2bfa74e.tar.xz
drm/gem-vram: handle NULL bo->resource in move callback
The ttm BO now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for ttm_bo_move_memcpy() users, like with vram-gem, since it just silently returns zero. This seems to then trigger warnings like: WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_gem_vram_helper.c:255 drm_gem_vram_offset (??:?) Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM, otherwise do the multi-hop sequence to ensure can safely call into ttm_bo_move_memcpy(), since it might also need to clear the memory. This should give the same behaviour as before. While we are here let's also treat calling ttm_bo_move_memcpy() with NULL bo->resource as programmer error, where expectation is that upper layers should now handle it. Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208145319.397235-1-matthew.auld@intel.com Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Diffstat (limited to 'drivers/gpu/drm/tegra/sor.h')
0 files changed, 0 insertions, 0 deletions