Lines Matching full:held
51 of dma_fences and a lock that needs to be held when adding
93 sleeping if the write side is held.
94 The write side is held by the core mm while calling mmu interval
131 held in relevant situations and also provides a means of making itself
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.
255 gpu_vms the object is bound to are typically not held. Only
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
323 Accessing the gpu_vm's lists without the dma_resv lock held
329 held, for example due to asynchronous state updates from within the
538 are held. When unlinking a gpu_vma the same locks should be held,
543 outer ``gpu_vm->lock`` is held, since otherwise when iterating over
560 must either introduce a new lock that is held at both mapping and
562 make sure that they are held also at mapping time. For userptr
563 gpu_vmas, the ``userptr_seqlock`` is held in write mode in the mmu
566 is held in read mode during mapping, it will not race with the
568 the GEM object's dma_resv and ensuring that the dma_resv is held also