[Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1
benh at kernel.crashing.org
Wed Apr 27 21:37:51 UTC 2011
On Wed, 2011-04-27 at 08:35 +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 21, 2011 at 09:29:16PM +0200, Arnd Bergmann wrote:
> > 1. Fix the arm version of dma_alloc_coherent. It's in use today and
> > is broken on modern CPUs because it results in both cached and
> > uncached mappings. Rebecca suggested different approaches how to
> > get there.
> I also suggested various approaches and produced patches, which I'm slowly
> feeding in. However, I think whatever we do, we'll end up breaking
> something along the line - especially as various places assume that
> dma_alloc_coherent() is ultimately backed by memory with a struct page.
Our implementation for embedded ppc has a similar problem. It currently
uses a pool of memory and does virtual mappings on it which means no
struct page easy to get to. How do you do on your side ? A fixed size
pool that you take out of the linear mapping ? Or you allocate pages in
the linear mapping and "unmap" them ? The problem I have with some
embedded ppc's is that the linear map is mapped in chunks of 256M or
> > 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.
I was about to ask what the point is ... (what is the expected
semantic ? Memory that is reachable but not necessarily cache
> > 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 indirected
> through that structure.
Why not ? That's the only way we can deal in my experience with multiple
type of different iommu's etc... at runtime in a single kernel. We used
to more/less have global function pointers in a long past but we moved
to per device ops instead to cope with multiple DMA path within a given
system and it works fine.
> 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.
Right. For now I don't have that problem on ppc as my iommu archs are
also fully coherent, so it's a bit more tricky that way but can be
handled I suppose by having the cache mgmnt be lib functions based on
flags added to the struct device.
> So you can't have a dma_map_ops for the cache handling bits, a dma_map_ops
> for IOMMU, and a dma_map_ops for the dmabounce stuff. It just doesn't
> work like that.
Well, the dmabounce and cache handling is one implementation that's just
on/off with parameters no ?. iommu is different implementations. So the
ops should be for the iommu backends. The dmabounce & cache handling is
then done by those backends based on flags you stick in struct device
> I believe the dma_map_ops stuff in asm-generic to be entirely unsuitable
> for ARM.
I don't think it is :-)
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
More information about the Linaro-mm-sig