[Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1
zach.pfeffer at linaro.org
Thu Apr 21 21:52:24 UTC 2011
> Arnd Bergmann <arnd at arndb.de> wrote:
>> I think the recent discussions on linaro-mm-sig and the BoF last week
>> at ELC have been quite productive, and at least my understanding
>> of the missing pieces has improved quite a bit. This is a list of
>> things that I think need to be done in the kernel. Please complain
>> if any of these still seem controversial:
>> 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.
>> 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.
>> 3. Convert ARM to use asm-generic/dma-mapping-common.h. We need
>> both IOMMU and direct mapped DMA on some machines.
> I don't think the DMA mapping and allocation APIs are sufficient for
> high performance graphics at least. It's fairly common to allocate a
> bunch of buffers necessary to render a scene, build up a command buffer
> that references them, then hand the whole thing off to the kernel to
> execute at once on the GPU. That allows for a lot of extra efficiency,
> since it allows you to batch the MMU binding until execution occurs (or
> even put it off entirely until the page is referenced by the GPU in the
> case of faulting support). It's also necessary to avoid livelocks
> between two clients trying to render; if mapping is incremental on both
> sides, it's possible that neither will be able to make forward
> progress due to IOMMU space exhaustion.
> So that argues for separating allocation from mapping both on the user
> side (which I think everyone agrees on) as well as on the kernel side,
> both for CPU access (which some drivers won't need) and for GPU access.
I agree with Jesse that the separation of mapping from allocation is
central to the current usage models. I realize most people didn't like
VCMM, but it provided an abstraction for this - if software can handle
the multiple mapper approach in a rational way across ARM than we can
solve a lot of problems with all the map and unmap current solutions
and we don't have to hack in coherency.
> Jesse Barnes, Intel Open Source Technology Center
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
More information about the Linaro-mm-sig