Partial cacheline flush problems on ARM and MIPS

[Warner Losh]

On Aug 23, 2012, at 6:51 PM, Ian Lepore wrote:

> 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?
>> 
> 
> Thinking about this some more, I think that at least for now we don't
> have to communicate a new constraint to bus_dma_tag_create(), nor do we
> need to assume that a size constraint is the same as an alignment
> constraint.  The size constraint is machine dependant in nature, and the
> busdma implementation code is also MD, and thus should have some MD way
> of knowing about this constraint for itself without being told by
> callers.

And also allow for different cache line sizes for different CPUs within the same MACHINE/MACHINE_ARCH, which is common in MIPS land, at least.

Warner