[Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1
m.szyprowski at samsung.com
Wed Apr 27 10:51:52 UTC 2011
On Wednesday, April 27, 2011 10:57 AM Arnd Bergmann wrote:
> On Wednesday 27 April 2011, Russell King - ARM Linux wrote:
> > > 2. Implement dma_alloc_noncoherent on ARM. Marek pointed out
> > > that this is needed, and it currently is not implemented, with
> > > an outdated comment explaining why it used to not be possible
> > > to do it.
> > dma_alloc_noncoherent is an entirely pointless API afaics.
> The main use case that I can see for dma_alloc_noncoherent is being
> able to allocate a large cacheable memory chunk that is mapped
> contiguous into both kernel virtual and bus virtual space, but not
> necessarily in contiguous in physical memory.
> Without an IOMMU, I agree that it is pointless, because the only
> sensible imlpementation would be alloc_pages_exact + dma_map_single.
Still it might be reasonable to use it in the drivers that will work
on different platforms - one with iommu and one without.
> > > 3. Convert ARM to use asm-generic/dma-mapping-common.h. We need
> > > both IOMMU and direct mapped DMA on some machines.
> > >
> > > 4. Implement an architecture independent version of dma_map_ops
> > > based on the iommu.h API. As Joerg mentioned, this has been
> > > missing for some time, and it would be better to do it once
> > > than for each IOMMU separately. This is probably a lot of work.
> > dma_map_ops design is broken - we can't have the entire DMA API
> > through that structure. Whether you have an IOMMU or not is completely
> > independent of whether you have to do DMA cache handling. Moreover, with
> > dmabounce, having the DMA cache handling in place doesn't make sense.
> > So you can't have a dma_map_ops for the cache handling bits, a
> > for IOMMU, and a dma_map_ops for the dmabounce stuff. It just doesn't
> > work like that.
> > I believe the dma_map_ops stuff in asm-generic to be entirely unsuitable
> > for ARM.
> We probably still need to handle both the coherent and noncoherent case
> in each dma_map_ops implementation, at least for those combinations where
> they matter (definitely the linear mapping). However, I think that using
> dma_mapping_common.h would let us use an architecture-independent
> for the generic iommu code that Marek wants to introduce now.
> I still don't understand how dmabounce works, but if it's similar to
> swiotlb, we can have at least three different dma_map_ops: linear,
> dmabounce and iommu.
That's exactly what I want to make in the initial version of my patches.
Samsung Poland R&D Center
More information about the Linaro-mm-sig