#
6b252cf4 |
|
04-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space. Hence, we a need a way to manipulate the MMUs page tables without going through the internal range allocator implemented by nvkm/vmm. This patch adds a raw interface for nvkm/vmm to pass the resposibility for managing the address space and the corresponding map/unmap/sparse operations to the upper layers. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-11-dakr@redhat.com
|
#
45faf3d7 |
|
29-Mar-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/nvif: give every vmm object a human-readable identifier Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
2606f291 |
|
13-Jun-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu: support initialisation of client-managed address-spaces NVKM is currently responsible for managing the allocation of a client's GPU address-space, but there's various use-cases (ie. HMM address-space mirroring) where giving a client more direct control is desirable. This commit allows for a VMM to be created where the area allocated for NVKM is limited to a client-specified window, the remainder of address- space is controlled directly by the client. Leaving a window is necessary to support various internal requirements, but also to support existing allocation interfaces as not all of the HW is capable of working with a HMM allocation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
920d2b5e |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu: define user interfaces to mmu vmm opertaions Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|