summaryrefslogtreecommitdiff
path: root/include/linux/timerqueue_types.h
diff options
context:
space:
mode:
authorAlice Ryhl <aliceryhl@google.com>2026-04-09 15:26:07 +0000
committerDanilo Krummrich <dakr@kernel.org>2026-05-05 12:52:49 +0200
commit71a3921111bd05298988fad1c58241db13384ea7 (patch)
tree2127184135031212b419d2825ea468fc24e6715c /include/linux/timerqueue_types.h
parent82b78182eacf82c1847c6f1fd93d91c15efb69cf (diff)
rust: gpuvm: add GpuVm::obtain()
This provides a mechanism to create (or look up) VMBO instances, which represent the mapping between GPUVM and GEM objects. The GpuVmBoRegistered<T> type can be considered like ARef<GpuVm<T>>, except that no way to increment the refcount is provided. The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVmBo<T>, so it's not really a GpuVmBo<T> yet. Its destructor could call drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently private and never called anywhere, this perf optimization does not need to happen now. Pre-allocating and obtaining the gpuvm_bo object is exposed as a single step. This could theoretically be a problem if one wanted to call drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical path, but that's not a possibility because: 1. Adding the BO to the extobj list requires the resv lock, so it cannot happen during the fence signalling critical path. 2. obtain() requires that the BO is not in the extobj list, so obtain() must be called before adding the BO to the extobj list. Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence signalling critical path. (For extobjs at least.) Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-2-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Diffstat (limited to 'include/linux/timerqueue_types.h')
0 files changed, 0 insertions, 0 deletions