[PATCH 3/3] swiotlb: Add support for CMA allocations

[Will Deacon]

On Tue, Dec 10, 2013 at 12:40:20AM +0000, Konrad Rzeszutek Wilk wrote:
> Laura Abbott <lauraa at codeaurora.org> wrote:
> >On 12/9/2013 4:29 PM, Konrad Rzeszutek Wilk wrote:
> >> Laura Abbott <lauraa at codeaurora.org> wrote:
> >>> Some architectures may implement the CMA APIs to allow allocation
> >>> of larger contiguous blocks of memory. Add support in the swiotlb
> >>> alloc/free functions to allocate from the CMA APIs instead of the
> >>> basic page allocator.
> >>>
> >>> Cc: Will Deacon <will.deacon at arm.com>
> >>> Cc: Catalin Marinas <catalin.marinas at arm.com>
> >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
> >>> Cc: Marek Szyprowski <m.szyprowski at samsung.com>
> >>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> >...
> >>>
> >>
> >> Can this be done in the platform dma_ops functions instead?
> >>
> >
> >I suppose it could but that seems like it would result in lots of 
> >duplicated code if every architecture that uses swiotlb wants to use
> >CMA.
> >
> >Thanks,
> >Laura
> 
> Then let's do that it that way. Thank you.

Note that once arch/arm64 starts growing things like support for non-coherent
DMA and IOMMU mappings, we'll probably want to factor out a bunch of the
boilerplat from our dma-mapping.c file into places like lib/iommu-helper.c.

However, until then, I can see this making sense to live in the arch-code.
Ultimately, the swiotlb code could just call a helper, but for now we can
rip-out the highmem parts (which doesn't leave much) and put it under
arch/arm64.

Will