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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110426083922.344bd8d6@jbarnes-desktop>
Date:	Tue, 26 Apr 2011 08:39:22 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	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

On Tue, 26 Apr 2011 16:26:19 +0200
Arnd Bergmann <arnd@...db.de> wrote:
> I don't thing that this argument has anything to do with what the
> underlying API should be, right? I can see this built on top of either
> the dma-mapping headers with extensions to map potentially uncached
> pages, and with the iommu API. Neither way would however save us from
> implementing the three items listed above.

Or simply extending the DMA mapping API to allow for allocations
without mapping.  I was just worried you had a more traditional driver
model in mind (e.g. coherent alloc on the ring buffer, single mappings
for data buffers, all mapped in the kernel driver at allocation time).

The DMA API does have some advantages, in that arches already support
it, there's some infrastructure for handling per-bus mapping, etc., so
building on top of it is probably a good idea.

> It's certainly a good point to note that we should have a way to
> allocate pages for a device without mapping them into any address
> space right away. My feeling is still that the dma mapping API is
> the right place for this, because it is the only part of the kernel
> that has knowledge about whether a device needs uncached memory for
> coherent access, under what constraints it can map noncontiguous
> memory into its own address space, and what its addressing capabilities
> are (dma mask).

Right.  Sometimes a device or platform can handle either cached or
uncached though, and we need userspace to decide on the best type for
performance reasons.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/