[PATCH v7] drm: Add library for shmem backed GEM objects

[Rob Herring]

On Wed, Mar 6, 2019 at 6:50 PM Eric Anholt <eric at anholt.net> wrote:
>
> Rob Herring <robh at kernel.org> writes:
>
> > From: Noralf Trønnes <noralf at tronnes.org>
> >
> > This adds a library for shmem backed GEM objects.
> >
> > v7:
> > - Use write-combine for mmap instead. This is the more common
> >   case. (robher)
> >
> > v6:
> > - Fix uninitialized variable issue in an error path (anholt).
> > - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
> >   of the pages (anholt).
> >
> > v5:
> > - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
> > - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real
> >   vma->vm_pgoff
> > - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct
> >
> > v4:
> > - Drop cache modes (Thomas Hellstrom)
> > - Add a GEM attached vtable
> >
> > v3:
> > - Grammar (Sam Ravnborg)
> > - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/
> >   (Sam Ravnborg)
> > - Add debug output in error path (Sam Ravnborg)
> >
> > Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> > Signed-off-by: Eric Anholt <eric at anholt.net>
> > Signed-off-by: Rob Herring <robh at kernel.org>
> > ---
> > I don't have a user to submit just yet, but we are using this for
> > panfrost which can be seen here[1]. I expect we'll be ready to merge
> > panfrost for 5.2.

I need to add exporting drm_gem_shmem_create_with_handle() as well. I
was thinking I was just using that in my rockchip conversion attempt,
but I need it for panfrost too.

> Excellent.  I'm taking a look at this for v3d, and I see that on the
> panfrost side you're allocating shmem->sgt and doing dma_map_sg() in
> your MMU map code, with no error handling.  And, on MMU unmap I see
> dma_unmap_sg() unconditionally (won't that unbalance for a prime import
> which will presumably do its own unmapping?), but it also looks like the
> sgt is not freed.

Indeed, I'll need to split those.

Error handling? Panfrost doesn't do that. ;)

> Can we do something nicer for handling the driver's desire for the sgt
> to fill its PTEs, regardless of where the BO came from?

Not sure I follow. You mean do something in shmem helpers? I'm
assuming when we pin and dma map will evolve from at BO creation time
to on demand.

> I also hope we can plug this into vkms and turn on prime sharing for it.

Doesn't seem too hard. I'd assume vkms would be okay with WC mappings
as it looks like they are currently cacheable? We could add a dma
attrs field to let users customize the mapping, but I'd rather avoid
that if possible.

Rob