On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott <labbott@xxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
