Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1363059 > unrolled thread

[RFC 0/2] staging: ion: of_ion_device_get

Back to article view | Back to linux.kernel

Contents

  [RFC 0/2] staging: ion: of_ion_device_get Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-22 23:40 +0100
    [RFC 2/2] staging: android: ion: Add of_ion_device_get function Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-22 23:40 +0100
      Re: [RFC 2/2] staging: android: ion: Add of_ion_device_get function Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-23 00:00 +0100
      Re: [RFC 2/2] staging: android: ion: Add of_ion_device_get function Dan Carpenter <dan.carpenter@oracle.com> - 2016-03-23 06:00 +0100
    Re: [RFC 0/2] staging: ion: of_ion_device_get Laura Abbott <labbott@redhat.com> - 2016-03-23 00:00 +0100
      Re: [RFC 0/2] staging: ion: of_ion_device_get Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-23 00:10 +0100
        Re: [RFC 0/2] staging: ion: of_ion_device_get Laura Abbott <labbott@redhat.com> - 2016-03-23 00:30 +0100
          Re: [RFC 0/2] staging: ion: of_ion_device_get Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-23 00:40 +0100
          Re: [RFC 0/2] staging: ion: of_ion_device_get Moritz Fischer <moritz.fischer@ettus.com> - 2016-03-23 00:50 +0100

#1363059 — [RFC 0/2] staging: ion: of_ion_device_get

Hi all,

probably I'm doing this all wrong. I'm playing around with a bunch of accelerators
and I need to share buffers between them. I have my heaps implemented as a
platform device and from what I understand I'll need a reference to the
struct ion_device in each of them.
I couldn't find a way to get to that via devicetree, though. I'll admit that hacking
up miscdevice is quite hacky, maybe I should add a foo_get_ion_device() to my
heap implementing platform device?
If someone can explain me how to correctly do that with what we currently have,
even better.

Cheers,

   Moritz

Moritz Fischer (2):
  misc: Add of_get_misc get a reference from devicetree
  staging: android: ion: Add of_ion_device_get function

 drivers/char/misc.c               | 38 ++++++++++++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion.c | 10 ++++++++++
 include/linux/miscdevice.h        |  3 +++
 3 files changed, 51 insertions(+)

-- 
2.7.4

[toc] | [next] | [standalone]

#1363060 — [RFC 2/2] staging: android: ion: Add of_ion_device_get function

Allows to obtain a reference to the global /dev/ion backing
struct ion_device via devicetree.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
---
 drivers/staging/android/ion/ion.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index e237e9f..cea264e0 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -64,6 +64,16 @@ struct ion_device {
 	struct dentry *clients_debug_root;
 };
 
+struct ion_device *of_ion_device_get(struct device_node *node)
+{
+	struct miscdevice *mdev = of_misc_get(node);
+
+	if (IS_ERR(mdev))
+		return ERR_PTR(PTR_ERR(mdev));
+
+	return container_of(mdev, struct ion_device, dev);
+}
+
 /**
  * struct ion_client - a process/hw block local address space
  * @node:		node in the tree of all clients
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1363068 — Re: [RFC 2/2] staging: android: ion: Add of_ion_device_get function

Derp,

On Tue, Mar 22, 2016 at 3:33 PM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
> Allows to obtain a reference to the global /dev/ion backing
> struct ion_device via devicetree.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> ---
>  drivers/staging/android/ion/ion.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index e237e9f..cea264e0 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -64,6 +64,16 @@ struct ion_device {
>         struct dentry *clients_debug_root;
>  };
>
> +struct ion_device *of_ion_device_get(struct device_node *node)
> +{
> +       struct miscdevice *mdev = of_misc_get(node);
> +
> +       if (IS_ERR(mdev))
> +               return ERR_PTR(PTR_ERR(mdev));
> +
> +       return container_of(mdev, struct ion_device, dev);
> +}
> +
>  /**
>   * struct ion_client - a process/hw block local address space
>   * @node:              node in the tree of all clients
> --
> 2.7.4
>

It's missing the header file ... if it's deemed useful at all I'll
clean up and resubmit.

Moritz

[toc] | [prev] | [next] | [standalone]

#1363201 — Re: [RFC 2/2] staging: android: ion: Add of_ion_device_get function

On Tue, Mar 22, 2016 at 03:33:51PM -0700, Moritz Fischer wrote:
> +struct ion_device *of_ion_device_get(struct device_node *node)
> +{
> +	struct miscdevice *mdev = of_misc_get(node);
> +
> +	if (IS_ERR(mdev))
> +		return ERR_PTR(PTR_ERR(mdev));

Use ERR_CAST() for this.

regarda,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1363067

On 03/22/2016 03:33 PM, Moritz Fischer wrote:
> Hi all,
>
> probably I'm doing this all wrong. I'm playing around with a bunch of accelerators
> and I need to share buffers between them. I have my heaps implemented as a
> platform device and from what I understand I'll need a reference to the
> struct ion_device in each of them.
> I couldn't find a way to get to that via devicetree, though. I'll admit that hacking
> up miscdevice is quite hacky, maybe I should add a foo_get_ion_device() to my
> heap implementing platform device?
> If someone can explain me how to correctly do that with what we currently have,
> even better.
>
> Cheers,
>
>     Moritz
>
> Moritz Fischer (2):
>    misc: Add of_get_misc get a reference from devicetree
>    staging: android: ion: Add of_ion_device_get function
>
>   drivers/char/misc.c               | 38 ++++++++++++++++++++++++++++++++++++++
>   drivers/staging/android/ion/ion.c | 10 ++++++++++
>   include/linux/miscdevice.h        |  3 +++
>   3 files changed, 51 insertions(+)
>

In the past what drivers have done is a foo_ion_client_create which has the reference
to the ion_device created from ion_device_create. Drivers then call the
foo_ion_client_create function.

Can you elaborate more on your sharing and allocation flow? This might suggest
another idea.

Thanks,
Laura

[toc] | [prev] | [next] | [standalone]

#1363093

Hi Laura,

On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott <labbott@redhat.com> wrote:

> In the past what drivers have done is a foo_ion_client_create which has the
> reference
> to the ion_device created from ion_device_create. Drivers then call the
> foo_ion_client_create function.

Oh, so you mean you add a function to create a client to the platform
device implementing
the heap and the export this function?

heap implements:

foo_create_client();

driver calls:

foo_create_client() ?

> Can you elaborate more on your sharing and allocation flow? This might
> suggest
> another idea.

Well I'll have a bunch of DMA streams to / from an FPGA that contains
DMA engines & accelerators. To that end
my userland software would allocate say 64 buffers, hand them over to
driver A to queue/deque them.

In future I might want to share these buffers between streams and with
other peripherals on the same bus,
which is why I looked at ION.

Thanks,

Moritz

[toc] | [prev] | [next] | [standalone]

#1363124

On 03/22/2016 04:08 PM, Moritz Fischer wrote:
> Hi Laura,
>
> On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott <labbott@redhat.com> wrote:
>
>> In the past what drivers have done is a foo_ion_client_create which has the
>> reference
>> to the ion_device created from ion_device_create. Drivers then call the
>> foo_ion_client_create function.
>
> Oh, so you mean you add a function to create a client to the platform
> device implementing
> the heap and the export this function?
>
> heap implements:
>
> foo_create_client();
>
> driver calls:
>
> foo_create_client() ?
>

Yes, exactly

>> Can you elaborate more on your sharing and allocation flow? This might
>> suggest
>> another idea.
>
> Well I'll have a bunch of DMA streams to / from an FPGA that contains
> DMA engines & accelerators. To that end
> my userland software would allocate say 64 buffers, hand them over to
> driver A to queue/deque them.
>
> In future I might want to share these buffers between streams and with
> other peripherals on the same bus,
> which is why I looked at ION.
>

If allocation is coming from userspace and drivers are only importing
you should be using the dma_buf APIs instead of Ion APIs directly.
Ion is a dma_buf exporter and dma_buf APIs are the preferred API.

> Thanks,
>
> Moritz
>

Thanks,
Laura

[toc] | [prev] | [next] | [standalone]

#1363129

On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott <labbott@redhat.com> wrote:
> On 03/22/2016 04:08 PM, Moritz Fischer wrote:
>>
>> Hi Laura,
>>
>> On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott <labbott@redhat.com> wrote:
>>
>>> In the past what drivers have done is a foo_ion_client_create which has
>>> the
>>> reference
>>> to the ion_device created from ion_device_create. Drivers then call the
>>> foo_ion_client_create function.
>>
>>
>> Oh, so you mean you add a function to create a client to the platform
>> device implementing
>> the heap and the export this function?
>>
>> heap implements:
>>
>> foo_create_client();
>>
>> driver calls:
>>
>> foo_create_client() ?
>>
>
> Yes, exactly
>
>>> Can you elaborate more on your sharing and allocation flow? This might
>>> suggest
>>> another idea.
>>
>>
>> Well I'll have a bunch of DMA streams to / from an FPGA that contains
>> DMA engines & accelerators. To that end
>> my userland software would allocate say 64 buffers, hand them over to
>> driver A to queue/deque them.
>>
>> In future I might want to share these buffers between streams and with
>> other peripherals on the same bus,
>> which is why I looked at ION.
>>
>
> If allocation is coming from userspace and drivers are only importing
> you should be using the dma_buf APIs instead of Ion APIs directly.
> Ion is a dma_buf exporter and dma_buf APIs are the preferred API.
>
>> Thanks,
>>
>> Moritz
>>
>
> Thanks,
> Laura

[toc] | [prev] | [next] | [standalone]

#1363132

On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott <labbott@redhat.com> wrote:

> If allocation is coming from userspace and drivers are only importing
> you should be using the dma_buf APIs instead of Ion APIs directly.
> Ion is a dma_buf exporter and dma_buf APIs are the preferred API.

Ok, thanks. Sounds reasonable.

Thanks,

Moritz

PS: My email skills today suck ... sorry about that ... I should go home ...

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web