On Fri, 22 Aug 2025 10:57:26 +0000
Alice Ryhl <[email protected]> wrote:
> On Fri, Aug 22, 2025 at 11:52:21AM +0200, Boris Brezillon wrote:
> > On Fri, 22 Aug 2025 09:28:24 +0000
> >
> > Maybe it's time we start moving some bits of the gpuva field docs next
> > to the fields they describe:
> >
> > /**
> > * @gpuva: Fields used by GPUVM to manage mappings pointing to this GEM
> > object.
> > */
> > struct {
> > /**
> > * @gpuva.list: list of GPU VAs attached to this GEM object.
> > *
> > * Drivers should lock list accesses with the GEMs &dma_resv
> > lock
> > * (&drm_gem_object.resv) or &drm_gem_object.gpuva.lock if the
> > * list is being updated in places where the resv lock can't be
> > * acquired (fence signalling path).
> > */
> > struct list_head list;
>
> This isn't a new issue, but it's somewhat confusing to call it a list of
> VAs when it's a list of vm_bos.
Yep, that's true.
>
> > /**
> > * @gpuva.lock: lock protecting access to
> > &drm_gem_object.gpuva.list
> > * when the resv lock can't be used.
> > *
> > * Should only be used when the VM is being modified in a fence
> > * signalling path, otherwise you should use
> > &drm_gem_object.resv to
> > * protect accesses to &drm_gem_object.gpuva.list.
> > */
> > struct mutex lock;
> >
> > ...
> > };
> >
>
> Alice
