Date: Thu, 23 Aug 2012 22:00:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@FreeBSD.org> Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS Message-ID: <F8C9E811-8597-4ED0-9F9D-786EB2301D6F@bsdimp.com> In-Reply-To: <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com> <1345765503.27688.602.camel@revolution.hippie.lan> <CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G%2BB9xB3NvPFJQ@mail.gmail.com> <1345766109.27688.606.camel@revolution.hippie.lan> <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 23, 2012, at 5:59 PM, Adrian Chadd wrote: > On 23 August 2012 16:55, Ian Lepore <freebsd@damnhippie.dyndns.org> = wrote: >=20 >>> In what case though would the hardware say it can only DMA on a 64k >>> alignment BUT move one byte at a time? Then what would the starting >>> address be for each DMA? >>>=20 >>=20 >> Maybe the device has a reduced number of address bits in its = registers >> and the low-order bits always start at zero and increment internally = in >> a wider register so that any length dma can happen, but it has to = start >> on a 64k boundary. >>=20 >> Maybe the address you pass it has to be a 64k boundary, but then the >> bytes actually end up in one-of-N slots within that 64k region, based = on >> other parameters of the transfer. >>=20 >> I've worked with some strange hardware over the years. >=20 > Right. That's pretty odd though. But now I understand where you're = coming from. >=20 > I still think the short term solution should be "fix the USB stack to > not do that!" >=20 > The longer term problem is likely to figure out what makes sense. Eg, > if you're going to allow the allocator to interleave 16 byte chunks > (on a 32 byte cache line platform) with some being DMA buffers and > others being non-DMA buffers; or whether you enforce that the whole > chunk is a DMA buffer for your hardware and you look after it, or > something else.. The bottom line is that you can't mix things like that when cache lines = are involved. The current code that tries is doomed to failure. Doomed. = You just can't control all flushes, as Ian's missive demonstrates, and = trying to accommodate code that does this I don't think can possibly = work. All the interrupt masking, copying in and out, etc I fear is = doomed to utter and abject failure. =20 Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8C9E811-8597-4ED0-9F9D-786EB2301D6F>