Lines Matching refs:userptr

8 including the userptr mmu_notifier locking. It also discusses some
9 optimizations to get rid of the looping through of all userptr mappings and
19 in this document. In particular, it is currently lacking a userptr
39 * ``userptr gpu_vma or just userptr``: A gpu_vma, whose backing store
81   gpu_vm's list of userptr gpu_vmas. With a CPU mm analogy this would
86   userptr gpu_vma on the gpu_vm's userptr list, and in write mode during mmu
103   invalidation. The userptr notifier lock is per gpu_vm.
193 might be userptr gpu_vmas that are not mapping a buffer object that
384 userptr gpu_vmas
387 A userptr gpu_vma is a gpu_vma that, instead of mapping a buffer object to a
420 the gpu_vm's list of userptr gpu_vmas needs to be protected by an
423 The MMU interval seqlock for a userptr gpu_vma is used in the following
429    // invalidated userptr gpu_vmas present, to avoid concurrent userptr
430    // revalidations of the same userptr gpu_vma.
447    // Final userptr sequence validation may not happen before the
472 what we call the ``userptr_seqlock``. In reality, the gpu_vm's userptr
474 userptr gpu_vmas, although we only show a single one here.
476 The userptr gpu_vma MMU invalidation notifier might be called from
505 accessing the old pages of the userptr gpu_vma and needs to redo the
508 Efficient userptr gpu_vma exec_function iteration
511 If the gpu_vm's list of userptr gpu_vmas becomes large, it's
513 exec function to check whether each userptr gpu_vma's saved
515 *invalidated* userptr gpu_vmas on a separate gpu_vm list and
526 If using an invalidated userptr list like this, the retry check in the
542 userptr gpu_vmas it's similarly required that during vma destroy, the
544 the invalidated userptr list as described in the previous section,
545 there is nothing keeping those userptr gpu_vmas alive.
562 make sure that they are held also at mapping time. For userptr