Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-08 Thread Sudip Mukherjee
On Thu, Jan 07, 2016 at 11:57:34AM +0300, Dan Carpenter wrote:
> Hm...  Perhaps I should be CC'ing LKML more often.  What's the rule on
> this, should I just send bugfixes to LKML and whitespace changes to only
> subsystem list?

All my patches (whitespace, bugfix, build fail) always has CC to lkml.
Infact, I have setup an alias for that so that i don't have to add lkml
manually everytime.

sm = send-email --cc=linux-ker...@vger.kernel.org

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-06 Thread Dan Carpenter
It's not really necessary to CC linux-kernel.  No one reads it.
I only send patches there when there isn't another public mailing
list available.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-06 Thread Linus Torvalds
On Wed, Jan 6, 2016 at 1:06 AM, Dan Carpenter  wrote:
> It's not really necessary to CC linux-kernel.  No one reads it.
> I only send patches there when there isn't another public mailing
> list available.

Actually, cc'ing lkml is still often a good idea, because it's a great
archiving point.

I know lots o people (and I am one) who are *not* on random mailing
lists that discuss particular subsystems, but that get lkml as an
auto-archived thing. Then, when cc'd, you see the back story - in a
way that you do *not* see with the random mailing list that was
specific to a particular subsystem.

There are also tools like patchworks that follow mailing lists - and
yes, it follows many different sublists, but not necessarily all.

Don't get me wrong: lkml is seldom - if ever - the _primary_ list. But
I would violently disagree with some kind of blanket "not really
necessary to CC linux-kernel" statement. It's still very useful
indeed, and it doesn't hurt to cc it for valid patches.

  Linus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-06 Thread Al Viro
On Wed, Jan 06, 2016 at 10:21:33AM -0800, Linus Torvalds wrote:
> On Wed, Jan 6, 2016 at 1:06 AM, Dan Carpenter  
> wrote:
> > It's not really necessary to CC linux-kernel.  No one reads it.

Some of us still do.

> > I only send patches there when there isn't another public mailing
> > list available.
> 
> Actually, cc'ing lkml is still often a good idea, because it's a great
> archiving point.

*nod*
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-06 Thread Jonathan Corbet
On Wed, 6 Jan 2016 12:06:22 +0300
Dan Carpenter  wrote:

> It's not really necessary to CC linux-kernel.  No one reads it.

I have to take issue with this too; more of us read it than you might
think.  The fact that we're probably all crazy doesn't really figure into
it.  Think of linux-kernel as the blockchain of kernel development; it's
a messy thing that takes a lot of resources to maintain (and keep up
with), but when you need to see what happened (or is happening) it's
invaluable.

jon
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-05 Thread Laura Abbott

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 
---
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 != _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 */




Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-05 Thread Rohit
Sorry to resend the patch without [RESEND] tag. Actually I had missed
to add  de...@driverdev.osuosl.org, linux-ker...@vger.kernel.org in
mail last time.

I will update the commit message with the explanation and send the
PATCHv2 soon.

Thanks,
Rohit

On Tue, 05 Jan 2016 10:12:39 -0800
Laura Abbott  wrote:

> 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 
> > ---
> > 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 != _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

[PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-05 Thread Rohit kumar
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 
---
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.

 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 != _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 */
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel