[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1400777250-17335-18-git-send-email-will.deacon@arm.com>
Date: Thu, 22 May 2014 17:47:29 +0100
From: Will Deacon <will.deacon@....com>
To: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: arnd@...db.de, monstr@...str.eu, dhowells@...hat.com,
broonie@...aro.org, benh@...nel.crashing.org, peterz@...radead.org,
paulmck@...ux.vnet.ibm.com, Will Deacon <will.deacon@....com>,
Randy Dunlap <rdunlap@...radead.org>
Subject: [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 <rdunlap@...radead.org>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Cc: David Howells <dhowells@...hat.com>
Signed-off-by: Will Deacon <will.deacon@....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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists