Re: [PATCH] Fix MMIO ops to provide expected barrier behaviour

[Segher Boessenkool <segher@kernel.crashing.org>]

> This changes the writeX family of functions to have a sync instruction
> before the MMIO store rather than after, because the generally  
> expected
> behaviour is that the device receiving the MMIO store can be  
> guaranteed
> to see the effects of any preceding writes to normal memory.

Yay, progress!

> To preserve ordering between writeX and readX, the readX family of
> functions have had an eieio added before the load.

readX() is supposed to be ordered to memory as well; the only
example I can think of where the difference would would show is
a readX() setting off a DMA; maybe such devices do not exist
anyway, but if you care, the eieio should be a full sync.

> Although writeX followed by spin_unlock is not officially guaranteed
> to keep the writeX inside the spin-locked region unless an mmiowb()
> is used, there are currently drivers that depend on the previous
> behaviour on powerpc, which was that the mmiowb wasn't actually  
> required.
> Therefore we have a per-cpu flag that is set by writeX, cleared by
> __raw_spin_lock and mmiowb, and tested by __raw_spin_unlock.  If it is
> set, __raw_spin_unlock does a sync and clears it.

Why is this done on 64-bit systems only?


Segher