On Mon, Oct 21, 2019 at 2:36 AM Brian Starkey wrote:
> On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote:
> > On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> > > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> > >
> > > As in v3:
> > >
> > > * Avoid EXPORT_SYMBOL
On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote:
> On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> >
> > As in v3:
> >
> > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by
> >Brian)
>
> Heh. I
On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
>
> As in v3:
>
> * Avoid EXPORT_SYMBOL until we finalize modules (suggested by
>Brian)
Heh. I guess it has been awhile. :)
> Did something change in that regard? I still
Hi John,
On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its own
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
