[PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf
Thomas Zimmermann
tzimmermann at suse.de
Thu May 14 07:23:37 UTC 2020
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> Currently this seems to work by converting the sgt into a pages array,
> and then treating it like a native object. Do the right thing and
> redirect mmap to the exporter.
>
> With this nothing is calling get_pages anymore on imported dma-buf,
> and we can start to remove the use of the ->pages array for that case.
>
> v2: Rebase
>
> Cc: Gerd Hoffmann <kraxel at redhat.com>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Noralf Trønnes <noralf at tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index b9cba5cc61c3..117a7841e284 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -551,6 +551,9 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> /* Remove the fake offset */
> vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
>
> + if (obj->import_attach)
> + return dma_buf_mmap(obj->dma_buf, vma, 0);
> +
Just a question: how does it work with the fake value in vm_pgoffset?
The offset is a DRM-specific thing and the dma-buf exporter expects the
real offset?
With this question clarified:
Acked-by: Thomas Zimmermann <tzimmermann at suse.de>
> shmem = to_drm_gem_shmem_obj(obj);
>
> ret = drm_gem_shmem_get_pages(shmem);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200514/5238c577/attachment-0001.sig>
More information about the dri-devel
mailing list