From: Laura Abbott <labbott@redhat.com>
To: Rohit kumar <rohit.kr@samsung.com>,
gregkh@linuxfoundation.org, arve@android.com,
riandrews@android.com, dan.carpenter@oracle.com,
gioh.kim@lge.com, sumit.semwal@linaro.org,
mitchelh@codeaurora.org, paul.gortmaker@windriver.com,
linux@rasmusvillemoes.dk, shawn.lin@rock-chips.com,
sriram@marirs.net.in, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org, pintu.k@samsung.com,
vishnu.ps@samsung.com
Cc: sreenathd@samsung.com, pintu_agarwal@yahoo.com,
me.rohit@live.com, cpgs@samsung.com
Subject: Re: [PATCH] staging/ion: Add support to get ion handle from dma buf
Date: Tue, 5 Jan 2016 10:12:39 -0800 [thread overview]
Message-ID: <568C0797.9010606@redhat.com> (raw)
In-Reply-To: <1451998982-15654-1-git-send-email-rohit.kr@samsung.com>
On 01/05/2016 05:03 AM, Rohit kumar wrote:
> Currently we can only import dma buf fd's to get ion_handle.
> Adding support to import dma buf handles to support kernel
> specific use cases.
>
> Signed-off-by: Rohit kumar <rohit.kr@samsung.com>
> ---
> Currently, ION is the memory manager for graphics in android. However,
> in other linux platforms such as Tizen, DRM-GEM is used for buffer
> management for graphics. It has gem_handle corresponding to a buffer
> and uses gem_name for sharing the buffer with other processes. However,
> it also uses dma_buf fd for 3d operations. For wayland, there are
> multiple calls for gem_handle to dma_buf fd conversion. So, we store
> dma_buf associated with buffer. But, there is no api for getting
> ion_handle from dma_buf. This patch exposes api to retrieve the ion
> handle from dma_buf for similar use cases. With this patch, we can
> integrate ION within DRM-GEM for buffer management and dma_buf sharing.
>
Is this the same patch that was sent on 12/29? In general it's best to
wait a bit longer before resending, especially with lots of people
being off for the holidays. Please also tag your patch with [RESEND]
so it's easier to tell that this is the same patch being sent again.
This is also a good explanation that should be included in the commit
text as well. It gives a much more thorough explanation why this
API is needed. The substance of the patch looks okay to me.
Thanks,
Laura
> drivers/staging/android/ion/ion.c | 21 +++++++++++++++------
> drivers/staging/android/ion/ion.h | 20 ++++++++++++++++----
> 2 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index e237e9f..5509716 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
> }
> EXPORT_SYMBOL(ion_share_dma_buf_fd);
>
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf)
> {
> - struct dma_buf *dmabuf;
> struct ion_buffer *buffer;
> struct ion_handle *handle;
> int ret;
>
> - dmabuf = dma_buf_get(fd);
> - if (IS_ERR(dmabuf))
> - return ERR_CAST(dmabuf);
> /* if this memory came from ion */
>
> if (dmabuf->ops != &dma_buf_ops) {
> @@ -1199,6 +1196,18 @@ end:
> }
> EXPORT_SYMBOL(ion_import_dma_buf);
>
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
> +{
> + struct dma_buf *dmabuf;
> +
> + dmabuf = dma_buf_get(fd);
> + if (IS_ERR(dmabuf))
> + return ERR_CAST(dmabuf);
> +
> + return ion_import_dma_buf(client, dmabuf);
> +}
> +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> +
> static int ion_sync_for_device(struct ion_client *client, int fd)
> {
> struct dma_buf *dmabuf;
> @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> {
> struct ion_handle *handle;
>
> - handle = ion_import_dma_buf(client, data.fd.fd);
> + handle = ion_import_dma_buf_fd(client, data.fd.fd);
> if (IS_ERR(handle))
> ret = PTR_ERR(handle);
> else
> diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
> index b860c5f..a1331fc 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client,
> int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle);
>
> /**
> - * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get handle
> + * ion_import_dma_buf() - get ion_handle from dma-buf
> + * @client: the client
> + * @dmabuf: the dma-buf
> + *
> + * Get the ion_buffer associated with the dma-buf and return the ion_handle.
> + * If no ion_handle exists for this buffer, return newly created ion_handle.
> + * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
> + */
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf);
> +
> +/**
> + * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get handle
> * @client: the client
> * @fd: the dma-buf fd
> *
> - * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
> - * import that fd and return a handle representing it. If a dma-buf from
> + * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf_fd,
> + * import that fd and return a handle representing it. If a dma-buf from
> * another exporter is passed in this function will return ERR_PTR(-EINVAL)
> */
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd);
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd);
>
> #endif /* _LINUX_ION_H */
>
next prev parent reply other threads:[~2016-01-05 18:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 13:03 [PATCH] staging/ion: Add support to get ion handle from dma buf Rohit kumar
2016-01-05 18:12 ` Laura Abbott [this message]
2016-01-06 5:25 ` Rohit
2016-01-06 9:06 ` Dan Carpenter
2016-01-06 18:21 ` Linus Torvalds
2016-01-06 18:24 ` Al Viro
2016-01-06 21:38 ` Jonathan Corbet
2016-01-07 8:57 ` Dan Carpenter
2016-01-09 4:44 ` Sudip Mukherjee
2016-01-06 7:11 ` [PATCHv2 1/1] " Rohit kumar
2016-01-06 18:26 ` Laura Abbott
2016-01-07 14:13 ` Sumit Semwal
2016-01-08 7:51 ` Rohit
2016-01-12 4:01 ` [PATCHv3 " Rohit kumar
2016-02-01 7:59 ` Rohit
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=568C0797.9010606@redhat.com \
--to=labbott@redhat.com \
--cc=arve@android.com \
--cc=cpgs@samsung.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gioh.kim@lge.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=me.rohit@live.com \
--cc=mitchelh@codeaurora.org \
--cc=paul.gortmaker@windriver.com \
--cc=pintu.k@samsung.com \
--cc=pintu_agarwal@yahoo.com \
--cc=riandrews@android.com \
--cc=rohit.kr@samsung.com \
--cc=shawn.lin@rock-chips.com \
--cc=sreenathd@samsung.com \
--cc=sriram@marirs.net.in \
--cc=sumit.semwal@linaro.org \
--cc=vishnu.ps@samsung.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).