Lines Matching refs:dma_resv

48 * ``dma_resv``: A struct dma_resv (a.k.a reservation object) that is used
50   gpu_vm or a GEM object. The dma_resv contains an array / list
52   additional dma_fences to the dma_resv. The lock is of a type that
64   single VM. Local GEM objects share the gpu_vm's dma_resv.
73 dma_resv object and hence the dma_resv lock. So, even with a huge
106   object's dma_resv, but some drivers protects this list differently,
112   with the dma_resv locks, a special scheme is needed when iterating
122 same as the GEM object's dma_resv, but if the driver
154 pseudo-code. In particular, the dma_resv deadlock avoidance algorithm
155 as well as reserving memory for dma_resv fences is left out.
173            // dma_resv to be held (it protects the gpu_vm_bo's list of
175            // dma_resv, it is already held at this point.
218 dma_resv lock such that ``obj->resv == gpu_vm->resv``.
221 objects have their dma_resv locked and, due to the above equality, also
222 the gpu_vm's dma_resv protecting the gpu_vm's evict list is locked.
230 code holding the object's dma_resv while revalidating will ensure a
245 per-gpu_vm list which is protected by the gpu_vm's dma_resv lock or
256 the object's private dma_resv can be guaranteed to be held. If there
263 both the gpu_vm's dma_resv and the object's dma_resv is held, and the
266 object's dma_resv.
323 Accessing the gpu_vm's lists without the dma_resv lock held
326 Some drivers will hold the gpu_vm's dma_resv lock when accessing the
328 drivers that need to access these lists without the dma_resv lock
364 avoid accessing the gpu_vm's list outside of the dma_resv lock
417 get_user_pages() unfortunately can't be used under a dma_resv lock
418 since that would violate the locking order of the dma_resv lock vs the
478 take any dma_resv lock nor the gpu_vm->lock from within it.
540 the ``gpu_vm->resv`` or the GEM object's dma_resv, that the gpu_vmas
568 the GEM object's dma_resv and ensuring that the dma_resv is held also