From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ben Widawsky <ben@bwidawsk.net>, dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org, Dave Airlie <airlied@redhat.com>
Subject: Re: [Linaro-mm-sig] [PATCH 6/7] drm/vgem: import support
Date: Thu, 23 Feb 2012 19:10:33 +0000 [thread overview]
Message-ID: <f80fcd$3j1g73@fmsmga001.fm.intel.com> (raw)
In-Reply-To: <1329938960-4903-8-git-send-email-ben@bwidawsk.net>
On Wed, 22 Feb 2012 20:29:19 +0100, Ben Widawsky <ben@bwidawsk.net> wrote:
> dma-buf import support. The function definitely needs some cleanup.
>
> When reading through this code, there are 3 cases to consider:
> 1. vgem exporter, vgem importer, same fd
> 2. vgem exporter, vgem importer, different fd
> 3. X expoter, vgem importer - not yet tested
>
> See the comments in the code for detailed explanation.
>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
> drivers/gpu/drm/vgem/vgem_dma_buf.c | 120 +++++++++++++++++++++++++++++++++++
> 1 files changed, 120 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c b/drivers/gpu/drm/vgem/vgem_dma_buf.c
> index eca9445..92c1823 100644
> --- a/drivers/gpu/drm/vgem/vgem_dma_buf.c
> +++ b/drivers/gpu/drm/vgem/vgem_dma_buf.c
> @@ -120,9 +120,129 @@ out_fd:
> return 0;
> }
>
> +/*
> + * Convert a dma-buf fd to a drm object handle, creating new object/handle as
> + * needed.
> + *
> + * There are 2 "interesting" cases we have to consider. The other, less interesting
> + * case is when importer == exporter, and drm_files are the same.
> + * vgem exporter
> + * The original exporter may or may not still hold a reference to the
> + * object by the time we reach here. Once we get a dma_buf reference though
> + * we know the original object cannot go away. Next we grab the prime mutex
> + * to prevent our lists from being screwed up from under us. We should next
> + * find the object in our global dma_buf hash. To make everything cool
> + * though we need to
> + * create a handle for the importer
> + * add the handle to the per file list
> + * drop the dma_buf reference
> + * the object can't go away due to us owning a file handle for it.
> + * In the end there should be 2 handle references, and 1 dma-buf reference.
> + *
> + * other exporter
> + * This case is very similar to the previous one. The primary difference is we
> + * do not want to drop the dma_buf reference since we know nothing about the
> + * reference counting from the exporter. So instead, we hold the dma_buf
> + * reference, but can drop the object reference. In the end of this case there
> + * should be 1 handle reference, and 1 dma-buf reference.
> + */
> int vgem_prime_to_handle(struct drm_device *dev,
> struct drm_file *file, int prime_fd,
> uint32_t *handle)
> {
> + struct drm_vgem_file_private *file_priv = file->driver_priv;
> + struct drm_vgem_gem_object *vobj = NULL;
> + struct drm_gem_object *obj = NULL;
> + struct dma_buf *dma_buf;
> + struct dma_buf_attachment *attach = NULL;
> + struct sg_table *sg = NULL;
> + bool drop_dma_buf_ref = false;
> + int ret;
> +
> + dma_buf = dma_buf_get(prime_fd);
> + if (IS_ERR(dma_buf))
> + return PTR_ERR(dma_buf);
> +
> + mutex_lock(&dev->prime_mutex);
> + /* First check that we don't dup on this file */
> + ret = drm_prime_lookup_fd_handle_mapping(&file_priv->prime, dma_buf,
> + handle);
> + if (ret == 0) {
> + DRM_DEBUG_PRIME("file_priv has an object for this dma_buf\n");
> + dma_buf_put(dma_buf);
> + mutex_unlock(&dev->prime_mutex);
> + return 0;
> + }
> +
> + /* Now check if we've already created/imported this object */
> + ret = drm_prime_lookup_obj(dev, dma_buf, &obj);
> + if (ret == 0 && obj != NULL) {
> + DRM_DEBUG_PRIME("driver has an object for this dma_buf\n");
> + drop_dma_buf_ref = true;
> + vobj = to_vgem_bo(obj);
> + goto handle_create;
> + }
> +
> + DRM_DEBUG_PRIME("Creating a new object for dma_buf\n");
> +
> + attach = dma_buf_attach(dma_buf, dev->dev);
> + if (IS_ERR(attach)) {
> + ret = PTR_ERR(attach);
> + goto fail_put;
> + }
> +
> + sg = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> + if (IS_ERR(sg)) {
> + ret = PTR_ERR(sg);
> + goto fail_detach;
> + }
> +
> + vobj = kzalloc(sizeof(*vobj), GFP_KERNEL);
> + if (vobj == NULL) {
> + ret = -ENOMEM;
> + goto fail_unmap;
> + }
> +
> + /* As a result of this mmap will not work -yet- */
> + ret = drm_gem_private_object_init(dev, &vobj->base, dma_buf->size);
> + if (ret) {
> + kfree(vobj);
> + ret = -ENOMEM;
> + goto fail_unmap;
> + }
> +
> + obj = &vobj->base;
Don't we need to store the backing attachment and prime_fd on the newly
created vgem obj?
> +
> +handle_create:
> + ret = drm_gem_handle_create(file, obj, handle);
> + if (ret)
> + return ret;
> +
> + ret = drm_prime_insert_fd_handle_mapping(&file_priv->prime,
> + dma_buf, *handle);
> + if (ret)
> + goto fail_handle;
> +
> + mutex_unlock(&dev->prime_mutex);
> +
> + if (drop_dma_buf_ref) {
> + /* This should mean we found this in the global hash */
> + dma_buf_put(dma_buf);
> + } else {
> + /* Handle holds the reference for the object we created */
> + drm_gem_object_unreference(obj);
> + }
> + return 0;
> +
> +fail_handle:
> + drm_gem_object_handle_unreference_unlocked(obj);
> +fail_unmap:
> + dma_buf_unmap_attachment(attach, sg);
> +fail_detach:
> + dma_buf_detach(dma_buf, attach);
> +fail_put:
> + dma_buf_put(dma_buf);
> + mutex_unlock(&dev->prime_mutex);
> +
> return 0;
> }
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-02-23 19:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 19:29 [PATCH 0/7] RFCv3 VGEM Prime (dma-buf) Ben Widawsky
2012-02-22 19:29 ` [PATCH 1/7] drm: base prime support Ben Widawsky
2012-02-22 19:58 ` Kristian Høgsberg
2012-02-27 2:49 ` InKi Dae
2012-02-22 19:29 ` [PATCH 2/7] DRM_DEBUG_PRIME Ben Widawsky
2012-02-22 19:29 ` [PATCH 2/7] drm: DRM_DEBUG_PRIME Ben Widawsky
2012-02-22 19:29 ` [PATCH 3/7] drm/vgem: virtual GEM provider Ben Widawsky
2012-02-22 19:29 ` [PATCH 4/7] drm: per device prime dma buf hash Ben Widawsky
2012-02-22 19:29 ` [PATCH 5/7] drm/vgem: prime export support Ben Widawsky
2012-02-23 19:00 ` [Linaro-mm-sig] " Chris Wilson
2012-02-27 13:37 ` Tomasz Stanislawski
2012-02-27 15:43 ` Tomasz Stanislawski
2012-02-29 15:50 ` Daniel Vetter
2012-02-22 19:29 ` [PATCH 6/7] drm/vgem: import support Ben Widawsky
2012-02-23 19:10 ` Chris Wilson [this message]
2012-02-23 23:00 ` [Linaro-mm-sig] " Chris Wilson
2012-02-22 19:29 ` [PATCH 7/7] drm: actually enable PRIME Ben Widawsky
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='f80fcd$3j1g73@fmsmga001.fm.intel.com' \
--to=chris@chris-wilson.co.uk \
--cc=airlied@redhat.com \
--cc=ben@bwidawsk.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.