From: Lucas Stach <l.stach@pengutronix.de>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Julien Boulnois <jboulnois@gmail.com>, dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers
Date: Fri, 25 May 2018 15:42:54 +0200 [thread overview]
Message-ID: <20180525134254.30686-2-l.stach@pengutronix.de> (raw)
In-Reply-To: <20180525134254.30686-1-l.stach@pengutronix.de>
The intention of the existing code was to deflect the actual work
of mmaping a dma-buf to the exporter, as that one probably knows best
how to handle the buffer. Unfortunately the call to drm_gem_mmap did
more than what etnaviv needs in this case by actually setting up the
mapping.
Move mapping setup to the shm buffer type mmap implementation so we
only need to look up the BO and call the buffer type mmap function
from the handler.
Fixes mmap behavior with dma-buf imported and userptr buffers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 30 ++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index fcc969fa0e69..f38989960d7f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -138,6 +138,13 @@ static int etnaviv_gem_mmap_obj(struct etnaviv_gem_object *etnaviv_obj,
struct vm_area_struct *vma)
{
pgprot_t vm_page_prot;
+ int ret;
+
+ ret = drm_gem_mmap_obj(&etnaviv_obj->base,
+ drm_vma_node_size(&etnaviv_obj->base.vma_node) << PAGE_SHIFT,
+ vma);
+ if (ret)
+ return ret;
vma->vm_flags &= ~VM_PFNMAP;
vma->vm_flags |= VM_MIXEDMAP;
@@ -167,17 +174,26 @@ static int etnaviv_gem_mmap_obj(struct etnaviv_gem_object *etnaviv_obj,
int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma)
{
- struct etnaviv_gem_object *obj;
+ struct drm_file *priv = filp->private_data;
+ struct etnaviv_gem_object *etnaviv_obj;
+ struct drm_gem_object *obj;
int ret;
- ret = drm_gem_mmap(filp, vma);
- if (ret) {
- DBG("mmap failed: %d", ret);
- return ret;
+ obj = drm_gem_bo_vm_lookup(filp, vma);
+ if (!obj)
+ return -EINVAL;
+
+ if (!drm_vma_node_is_allowed(&obj->vma_node, priv)) {
+ drm_gem_object_put_unlocked(obj);
+ return -EACCES;
}
- obj = to_etnaviv_bo(vma->vm_private_data);
- return obj->ops->mmap(obj, vma);
+ etnaviv_obj = to_etnaviv_bo(obj);
+
+ ret = etnaviv_obj->ops->mmap(etnaviv_obj, vma);
+ drm_gem_object_put_unlocked(obj);
+
+ return ret;
}
int etnaviv_gem_fault(struct vm_fault *vmf)
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-05-25 13:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 13:42 [PATCH 1/2] drm: split out buffer lookup from fake VMA offset Lucas Stach
2018-05-25 13:42 ` Lucas Stach [this message]
2018-05-29 8:20 ` [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers Daniel Vetter
2018-05-29 9:08 ` Lucas Stach
2018-05-29 12:34 ` Daniel Vetter
2018-05-31 8:41 ` Lucas Stach
2018-06-18 8:06 ` Daniel Vetter
2019-07-03 10:47 ` Lucas Stach
2019-07-03 13:16 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180525134254.30686-2-l.stach@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=jboulnois@gmail.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).