> > +int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
> > +{
> > + unsigned int pool_size_order = get_order(atomic_pool_size);
> > + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
> > + struct page *page;
> > + void *addr;
> > + int ret;
> > +
> > + if (dev_get_cma_ar
On Mon, Nov 05, 2018 at 01:19:26PM +0100, Christoph Hellwig wrote:
> The arm64 codebase to implement coherent dma allocation for architectures
> with non-coherent DMA is a good start for a generic implementation, given
> that is uses the generic remap helpers, provides the atomic pool for
> allocat
On Fri, Nov 30, 2018 at 07:05:23PM +, Robin Murphy wrote:
> It's a bit yuck that we now end up with arch_* hooks being a mix of arch
> code and not-actually-arch-code, but I guess there's some hope of coming
> back and streamlining things in future once all the big moves are done.
Yes, I hop
On 05/11/2018 12:19, Christoph Hellwig wrote:
The arm64 codebase to implement coherent dma allocation for architectures
with non-coherent DMA is a good start for a generic implementation, given
that is uses the generic remap helpers, provides the atomic pool for
allocations that can't sleep and s
Hi Christoph,
Minor nit: typo in the subject "ncoherent".
On Mon, Nov 05, 2018 at 01:19:26PM +0100, Christoph Hellwig wrote:
> The arm64 codebase to implement coherent dma allocation for architectures
> with non-coherent DMA is a good start for a generic implementation, given
> that is uses the g
The arm64 codebase to implement coherent dma allocation for architectures
with non-coherent DMA is a good start for a generic implementation, given
that is uses the generic remap helpers, provides the atomic pool for
allocations that can't sleep and still is realtively simple and well
tested. Move
