[PATCH v2 17/18] 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 Cc: Benjamin Herrenschmidt Cc: Paul E. McKenney Cc: David Howells Signed-off-by: Will Deacon --- Documentation/memory-barriers.txt | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 556f951f8626..f31c88691ee9 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -2462,10 +2462,15 @@ functions: Please refer to the PCI specification for more information on interactions between PCI transactions. - (*) readX_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. + (*) readX_relaxed(), writeX_relaxed() + + 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() -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 17/18] 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 rdun...@infradead.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: David Howells dhowe...@redhat.com Signed-off-by: Will Deacon will.dea...@arm.com --- Documentation/memory-barriers.txt | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 556f951f8626..f31c88691ee9 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -2462,10 +2462,15 @@ functions: Please refer to the PCI specification for more information on interactions between PCI transactions. - (*) readX_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. + (*) readX_relaxed(), writeX_relaxed() + + 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() -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/