linux-kernel - Re: [Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1

Open Source and information security mailing list archives

Message-ID: <BANLkTim5umALqafjA2e88UCLzMp9LQu3_Q@mail.gmail.com>
Date:	Thu, 21 Apr 2011 16:52:24 -0500
From:	Zach Pfeffer <zach.pfeffer@...aro.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Arnd Bergmann <arnd@...db.de>, linaro-mm-sig@...ts.linaro.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1

> Arnd Bergmann <arnd@...db.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@...ts.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives