Date: Mon, 21 May 2012 14:27:42 -0500 From: Mark Tinguely <marktinguely@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Richard Hodges <richard@hodges.org>, freebsd-arm@freebsd.org, hackers@freebsd.org, Svatopluk Kraus <onwahe@gmail.com> Subject: Re: ARM + CACHE_LINE_SIZE + DMA Message-ID: <CAP%2BM-_FO-WcpWassMMW9mffuc7tHSOqzwhBNfx56nZYnyiYNFg@mail.gmail.com> In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> References: <CAFHCsPUdZXGKFvmVGgaEUsfhwd28mNVGaY84ExcJp=ogQxzPJQ@mail.gmail.com> <1337285248.1503.308.camel@revolution.hippie.lan> <CAFHCsPVxkhNfiTQp7gvjfonfTjoG-28RgNrG=%2BdxbGhzxqY%2BDg@mail.gmail.com> <1337617221.2516.38.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 21, 2012 at 11:20 AM, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote: > On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: >> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore >> <freebsd@damnhippie.dyndns.org> wrote: >> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: >> >> Hi, >> >> >> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've >> >> looked at implementation in ARM tree, but IMHO it only works with som= e >> >> assumptions. There is a problem with DMA on memory block which is not >> >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. >> >> >> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. >> >> Then first cache line associated with the buffer can be divided into >> >> two parts, A and B, where A is a memory we know nothing about it and = B >> >> is buffer memory. The same stands for last cache line associatted wit= h >> >> the buffer. We have no problem if a memory is coherent. Otherwise it >> >> depends on memory attributes. ... > My suggestion of making a temporary writable mapping was the answer to > how to correctly change memory attributes on a page which is in use, at > least in the existing code, which is for a single processor. > > You don't need, and won't even use, the temporary mapping. =A0You would > make it just because doing so invokes logic in arm/arm/pmap.c which will > find all existing virtual mappings of the given physical pages, and > disable caching in each of those existing mappings. =A0In effect, it make= s > all existing mappings of the physical pages DMA_COHERENT. =A0When you > later free the temporary mapping, all other existing mappings are > changed back to being cacheable (as long as no more than one of the > mappings that remain is writable). > > I don't know that making a temporary mapping just for its side effect of > changing other existing mappings is a good idea, it's just a quick and > easy thing to do if you want to try changing all existing mappings to > non-cacheable. =A0It could be that a better way would be to have the > busdma_machdep code call directly to lower-level routines in pmap.c to > change existing mappings without making a new temporary mapping in the > kernel pmap. =A0The actual changes to the existing mappings are made by > pmap_fix_cache() but that routine isn't directly callable right now. > > Also, as far as I know all of this automatic disabling of cache for > multiple writable mappings applies only to VIVT cache architectures. > I'm not sure how the pmap code is going to change to support VIPT and > PIPT caches, but it may no longer be true that making a second writable > mapping of a page will lead to changing all existing mappings to > non-cacheable. > > -- Ian We don't want to carry the VIVT cache fixing code to VIPT/PIPT. I like the x86 approach of marking the page with a cache type (default/device/uncached/etc). The page mapping routines (for example pmap_qenter() on a clustered write) will honor that cache type in all future mappings. It is easy to implement. Other allocations, such as page tables, can benefit from an attributed allocation too. I also like having a separate allocator for the sub-page bus_dmamem_alloc() requests that want uncached buffers. These entries can stick around for a long time. If we just malloced the entries, then the other threads that happen to allocate data from the same page are penalized with uncached buffers too. --Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP%2BM-_FO-WcpWassMMW9mffuc7tHSOqzwhBNfx56nZYnyiYNFg>