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

[Eric Anholt]

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.

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.

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?

I also hope we can plug this into vkms and turn on prime sharing for it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190306/69474d70/attachment.sig>