Partial cacheline flush problems on ARM and MIPS

[Ian Lepore]

On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote:
> On 23 August 2012 16:45, Ian Lepore <freebsd at 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