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: Will Deacon <will.deacon@arm.com>
This commit is contained in:
Родитель
cbc908ef8e
Коммит
a8e0aead70
|
@ -2465,10 +2465,15 @@ functions:
|
|||
Please refer to the PCI specification for more information on interactions
|
||||
between PCI transactions.
|
||||
|
||||
(*) readX_relaxed()
|
||||
(*) readX_relaxed(), writeX_relaxed()
|
||||
|
||||
These are similar to readX(), but are not guaranteed to be ordered in any
|
||||
way. Be aware that there is no I/O read barrier available.
|
||||
These are similar to readX() and writeX(), but provide weaker memory
|
||||
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()
|
||||
|
||||
|
|
Загрузка…
Ссылка в новой задаче