diff options
author | Matthew Auld <matthew.auld@intel.com> | 2023-02-08 17:53:16 +0300 |
---|---|---|
committer | Christian König <christian.koenig@amd.com> | 2023-02-23 12:29:00 +0300 |
commit | c604d31950d10db45267bbcb9ce8f1dbc2bfa74e (patch) | |
tree | 39a1ededd9f44c537d03bf8310f1267df34a050f /drivers/gpu/drm/tegra/sor.h | |
parent | 4d5a2cce47a8e1e7119a881a4714f0eee557c1cd (diff) | |
download | linux-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