[PATCH] Fix MMIO ops to provide expected barrier behaviour
Segher Boessenkool
segher at kernel.crashing.org
Wed Sep 13 20:41:01 EST 2006
> 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
More information about the Linuxppc-dev
mailing list