Date: Thu, 27 Dec 2012 09:34:25 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Peter Jeremy <peter@rulingia.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Olivier Houchard <cognet@freebsd.org> Subject: Re: svn commit: r244469 - head/sys/arm/arm Message-ID: <1356626065.1144.79.camel@revolution.hippie.lan> In-Reply-To: <20121224211921.GA54928@server.rulingia.com> References: <201212200035.qBK0ZRU0022739@svn.freebsd.org> <20121224211921.GA54928@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-12-25 at 08:19 +1100, Peter Jeremy wrote: > On 2012-Dec-20 00:35:27 +0000, Olivier Houchard <cognet@FreeBSD.org> wrote: > >Author: cognet > >Date: Thu Dec 20 00:35:26 2012 > >New Revision: 244469 > >URL: http://svnweb.freebsd.org/changeset/base/244469 > > > >Log: > > Use the new allocator in bus_dmamem_alloc(). > > > >Modified: > > head/sys/arm/arm/busdma_machdep-v6.c > > Do you have any plans to make similar changes to the other busdma_machdep.c > files? > I wrote that allocator code to address some specific needs of architectures that use software-assisted cache coherency rather than hardware bus snooping. On such platforms, the bus_dmamem_alloc() implementations treat BUS_DMA_COHERENT as a request for uncacheable memory, and some drivers have come to rely on that for correct operation. (The concept is valid, overloading BUS_DMA_COHERENT to have different meanings on different platforms, maybe not so much so.) The old code on arm had the side effect of making an entire page uncacheable if any small dma buffer got allocated within that page. That was bad for performance, but it worked. When armv6 came along that caused problems with ldrex/strex instructions, which will fault if they operate on uncacheable memory. So the main thrust of the allocation changes was to make it easy to efficiently allocate small(-ish) dma buffers from a pool of pages that have caching turned off, without accidentally affecting memory that isn't being used for dma buffers. A nice secondary benefit is that they help eliminate partial cacheline flushes, because the allocator ensures that all dma buffers are aligned and padded to cacheline boundaries. So any busdma implementation that has similar needs can benefit from the new allocator code. I was thinking MIPS would be a good candidate, but I've only glanced at the mips code and noted its superficial similarity to the arm code. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1356626065.1144.79.camel>