Commit a8e0aead authored by Will Deacon's avatar Will Deacon

documentation: memory-barriers: clarify relaxed io accessor semantics

This patch extends the paragraph describing the relaxed read io accessors
so that the relaxed accessors are defined to be:

 - Ordered with respect to each other if accessing the same peripheral

 - Unordered with respect to normal memory accesses

 - Unordered with respect to LOCK/UNLOCK operations

Whilst many architectures will provide stricter semantics, ARM, Alpha and
PPC can achieve significant performance gains by taking advantage of some
or all of the above relaxations.

Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
parent cbc908ef
...@@ -2465,10 +2465,15 @@ functions: ...@@ -2465,10 +2465,15 @@ functions:
Please refer to the PCI specification for more information on interactions Please refer to the PCI specification for more information on interactions
between PCI transactions. between PCI transactions.
(*) readX_relaxed() (*) readX_relaxed(), writeX_relaxed()
These are similar to readX(), but are not guaranteed to be ordered in any These are similar to readX() and writeX(), but provide weaker memory
way. Be aware that there is no I/O read barrier available. ordering guarantees. Specifically, they do not guarantee ordering with
respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
ordering with respect to LOCK or UNLOCK operations. If the latter is
required, an mmiowb() barrier can be used. Note that relaxed accesses to
the same peripheral are guaranteed to be ordered with respect to each
other.
(*) ioreadX(), iowriteX() (*) ioreadX(), iowriteX()
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment