[RFC] ARM DMA mapping TODO, v1

Catalin Marinas catalin.marinas at arm.com
Wed Apr 27 10:29:30 EDT 2011


On Wed, 2011-04-27 at 15:06 +0100, FUJITA Tomonori wrote:
> On Wed, 27 Apr 2011 10:52:25 +0100
> Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> > Anyway, we end up with different DMA ops per device via dev_archdata.
> 
> Several architectures already do. What's wrong with the approach for
> arm?

Nothing wrong IMHO but it depends on how you group the DMA ops as it may
not be feasible to have all the combinations dmabounce/iommu/coherency
combinations. I think the main combinations would be:

1. standard (no-iommu) + non-coherent
2. standard (no-iommu) + coherent
3. iommu + non-coherent
4. iommu + coherent
5. dmabounce + non-coherent
6. dmabounce + coherent

I think dmabounce and iommu can be exclusive (unless the iommu cannot
access the whole RAM). If that's the case, we can have three type of DMA
ops:

1. standard
2. iommu
3. dmabounce

with an additional flag via dev_archdata for cache coherency level (a
device may be able to snoop the L1 or L2 cache etc.)

-- 
Catalin





More information about the linux-arm-kernel mailing list