search for: drm_gpuvm

Implement reference counting for struct drm_gpuvm. Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/drm_gpuvm.c | 56 +++++++++++++++++++++----- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 ++++++--- include/drm/drm_gpuvm.h | 31 +++++++++++++- 3 files changed, 90 insertions(+), 17 deletion...

...port a >>> destructor for the base-class, rather than to have the base-class >>> provide the refcount and a destructor? ops. > > GPUVM simply follows the same pattern we have with drm_gem_objects. > And I think it makes > sense. Why would we want to embed two struct drm_gpuvm in a single > driver structure? Because you need one drm_gpuvm structure for each application using the driver? Or am I missing something? As far as I can see a driver would want to embed that into your fpriv structure which is allocated during drm_driver.open callback. > >> >&...

...9;s subclass provide get() and put() ops, and export a destructor for the base-class, rather than to have the base-class provide the refcount and a destructor? ops. GPUVM simply follows the same pattern we have with drm_gem_objects. And I think it makes sense. Why would we want to embed two struct drm_gpuvm in a single driver structure? > > Well, I have never seen stuff like that in the kernel. Might be that this works, but I would rather not try if avoidable. > >> >> That would also make it possible for the driver to decide the context for the put() call: If the driver needs t...

...destructor for the base-class, rather than to have the base-class >>>> provide the refcount and a destructor? ops. >> >> GPUVM simply follows the same pattern we have with drm_gem_objects. >> And I think it makes >> sense. Why would we want to embed two struct drm_gpuvm in a single >> driver structure? > > Because you need one drm_gpuvm structure for each application using > the driver? Or am I missing something? > > As far as I can see a driver would want to embed that into your fpriv > structure which is allocated during drm_driver.ope...

...n >> drm_gem_object_funcs.close. >> >> Since it is perfectly legal for userspace to close a BO while there >> are still mappings (can trivial be that the app is killed) I would >> expect that the drm_gem_object_funcs.close handling is something like >> asking drm_gpuvm destroying the VM_BO and getting the mappings which >> should be cleared in the page table in return. >> >> In amdgpu we even go a step further and the VM structure keeps track >> of all the mappings of deleted VM_BOs so that higher level can query >> those and clea...

...object_funcs.close. >>> >>> Since it is perfectly legal for userspace to close a BO while there >>> are still mappings (can trivial be that the app is killed) I would >>> expect that the drm_gem_object_funcs.close handling is something >>> like asking drm_gpuvm destroying the VM_BO and getting the mappings >>> which should be cleared in the page table in return. >>> >>> In amdgpu we even go a step further and the VM structure keeps track >>> of all the mappings of deleted VM_BOs so that higher level can query >&gt...

...DRM: MM: using COPY for buffer copies ------------[ cut here ]------------ nouveau 0000:01:00.0: drm_WARN_ON(!found_head) WARNING: CPU: 4 PID: 786 at drivers/gpu/drm/nouveau/dispnv50/disp.c:2731 nv50_display_init+0x28c/0x4f0 [nouveau] Modules linked in: nouveau(+) drm_ttm_helper ttm video drm_exec drm_gpuvm gpu_sched drm_display_helper wmi CPU: 4 PID: 786 Comm: systemd-udevd Not tainted 6.6.0+ #1 Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7599/870-C45 (MS-7599), BIOS V1.15 03/04/2011 RIP: 0010:nv50_display_init+0x28c/0x4f0 [nouveau] Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 6d 47 37 e1 48 c...