Date: Thu, 23 Aug 2012 17:55:09 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> 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: <1345766109.27688.606.camel@revolution.hippie.lan> In-Reply-To: <CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G%2BB9xB3NvPFJQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote: > On 23 August 2012 16:45, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote: > > > So do you think it's safe to assume that any given dma tag that has an > > alignment constraint also implicitly has a buffer size constraint that > > the size must be a multiple of the alignment? > > > > What if we have a platform with a 32-byte cacheline / DMA granularity, > > and then we have a builtin device on that SoC which can only do DMA on a > > 64K alignment (which its tag would reflect), but the hardware can move > > as little as 1 byte at a time? Children of that bridge device come > > along and allocate little 16-byte buffers that eat 16 pages each. It > > doesn't seem all that far-fetched to me. > > That hardware would suck, wouldn't it? > > 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? > 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. 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. I've worked with some strange hardware over the years. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1345766109.27688.606.camel>