Partial cacheline flush problems on ARM and MIPS

Adrian Chadd adrian at freebsd.org
Mon Aug 27 16:53:31 UTC 2012


On 27 August 2012 09:08, Ian Lepore <freebsd at damnhippie.dyndns.org> wrote:

> If two DMAs are going on concurrently in the same buffer, one is going
> to finish before the other, leading to a POSTxxxx sync op happening for
> one DMA operation while the other is still in progress.  The unit of
> granularity for sync operations is the mapped region, so now you're
> syncing access to a region which still has active DMA happening within
> it.

Right. But the enforced idea is "DMA up to this point should be
flushed to memory."

> While I think it's really an API definition issue, think about it in
> terms of a potential implementation... What if the CPU had to access the
> memory as part of the sync for the first DMA that completes, while the
> second is still running?  Now you've got pretty much exactly the same
> situation as when a driver subdivides a buffer without knowing about the
> cache alignment; you end up with the CPU and DMA touching data in the
> same cachline and no sequence of flush/invalidate can be g'teed to
> preserve all data correctly.

Right. So you realise at that point you can't win and you stick each
of those pieces in a different cache line.


Adrian


More information about the freebsd-arm mailing list