[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56F1D33A.9050509@redhat.com>
Date: Tue, 22 Mar 2016 16:20:26 -0700
From: Laura Abbott <labbott@...hat.com>
To: Moritz Fischer <moritz.fischer@...us.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Greg KH <gregkh@...uxfoundation.org>, arve@...roid.com,
riandrews@...roid.com, Sumit Semwal <sumit.semwal@...aro.org>,
dan.carpenter@...cle.com, sriram@...irs.net.in,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
devel@...verdev.osuosl.org
Subject: Re: [RFC 0/2] staging: ion: of_ion_device_get
On 03/22/2016 04:08 PM, Moritz Fischer wrote:
> Hi Laura,
>
> On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott <labbott@...hat.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
Powered by blists - more mailing lists