This whole thread also ties in with my posts about mmiowb (which IMO
should go away).
readl/writel: strongly ordered wrt one another and other stores
to cacheable RAM, byteswapping
__readl/__writel: not ordered (needs mb/rmb/wmb to order with
other readl/writel and cacheable operations, or
io_*mb to order with one another)
raw_readl/raw_writel: strongly ordered, no byteswapping
__raw_readl/__raw_writel: not ordered, no byteswapping
then get rid of *relaxed* variants.
Linus: on x86, memory operations to wc and wc+ memory are not ordered
with one another, or operations to other memory types (ie. load/load
and store/store reordering is allowed). Also, as you know, store/load
reordering is explicitly allowed as well, which covers all memory
types. So perhaps it is not quite true to say readl/writel is strongly
ordered by default even on x86. You would have to put in some
mfence instructions in them to make it so.
So, what *exact* definition are you going to mandate for readl/writel?
Anything less than strict ordering then we also need to ensure drivers
use the correct barriers (to implement strict ordering, we could either
put mfence instructions in, or explicitly disallow readl/writel to be
used on wc/wc+ memory).
The other way we can go is just say that they have x86 semantics,
although that would be a bit sad IMO: we should have strong ops, in
which case driver writers never need to use a single barrier provided
they have locking right, and weak ops, in which case they should match
up with the weak Linux memory ordering model for system RAM.
--
