[PATCH] ARM: mm: dma: Update coherent streaming apis with missing memory barrier

Russell King - ARM Linux linux at arm.linux.org.uk
Thu Apr 24 04:15:47 PDT 2014


On Thu, Apr 24, 2014 at 11:47:37AM +0100, Catalin Marinas wrote:
> On Wed, Apr 23, 2014 at 08:04:48PM +0100, Russell King - ARM Linux wrote:
> > What is done on down-stream buses is of no concern to the behaviour of
> > the CPU, which is what's being discussed here (in terms of barriers.)
> > and the correct CPU ordering of various read/writes to memory and
> > devices vs the streaming cache operations.
> 
> It is still of concern because for cases like NAPI an rmb() on the CPU
> side is no longer enough. If you use a common network driver, written
> correctly with rmb(), but you have some weird interconnect which doesn't
> ensure ordering, you have to add interconnect specific barrier to the
> rmb() (or hack the dma ops like mvebu). I consider such hardware broken.

Yes, the hardware /is/ broken, but if you want to get it working in a
way that's acceptable in upstream kernels, adding that barrier to rmb()
is probably the only acceptable solution - especially if you have other
stuff going in between the rmb() and the DMA unmap.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.



More information about the linux-arm-kernel mailing list