Messages in this thread | | | Subject | Re: [RFC 0/2] staging: ion: of_ion_device_get | From | Laura Abbott <> | Date | Tue, 22 Mar 2016 16:20:26 -0700 |
| |
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
| |