Re: [PATCH 2/3] define ARM-specific dma_coherent_write_sync

[Catalin Marinas <catalin.marinas@arm.com>]

On Mon, Oct 03, 2011 at 02:40:19AM +0100, Jon Masters wrote:
> On Sep 6, 2011, at 11:02 AM, Mark Salter wrote:
> > In any case, the current thinking is that the original problem with
> > the USB performance seen on cortex A9 multicore is probably something
> > more than just write buffer delays. Once the original problem is better
> > understood, we can take another look at this patch if it is still
> > needed.
> 
> Thanks again for looking into this Mark. My understanding is that this
> is still being investigated. I'll followup with ARM to see how that's
> going since I've heard nothing recently :) Meanwhile, we're continuing
> to carry a hack based on these patches in Fedora ARM kernels.

Not talking about hardware specifics here, the architecture (though
ARMv7 onwards) mandates that the write buffer is eventually drained. But
doesn't state any upper limit, so it could even be half a second.

In this case, some form of buffer draining for devices that poll the
memory may be useful. If we don't want to add a new API, something like
below would work as well:

	write to DMA buffer;
	mb();
	read from DMA buffer;

So an mb() between the last write and a subsequent read would force the
visibility of the write. We have similar scenarios for Device accesses.

If we go for a DMA API extension, the dma_coherent_write_sync() should
probably take an address as well, just in case implementations would
force the draining via some read back from the same area.

-- 
Catalin