Thread (15 messages) 15 messages, 8 authors, 2013-06-23
STALE4732d

[PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio()

From: Russell King - ARM Linux <hidden>
Date: 2012-09-28 14:29:14

On Fri, Sep 28, 2012 at 03:13:42PM +0100, Catalin Marinas wrote:
On 28 September 2012 14:36, Arnd Bergmann [off-list ref] wrote:
quoted
On Thursday 27 September 2012, Russell King wrote:
quoted
+#ifndef __ARMBE__
+static inline void memset_io(volatile void __iomem *dst, unsigned c,
+       size_t count)
+{
+       memset((void __force *)dst, c, count);
+}
+#define memset_io(dst,c,count) memset_io(dst,c,count)
+
+static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
+       size_t count)
+{
+       memcpy(to, (const void __force *)from, count);
+}
+#define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
+
I wonder whether we need any barriers here. PowerPC has the strongest
barriers befor eand after the access, at least since f007cacffc8870
"[POWERPC] Fix MMIO ops to provide expected barrier behaviour".
In theory, we need barriers but only at the beginning and the end of
the operation, not for every iteration (and in practice we might even
be OK without any).
Yes, we at least need a barrier before each.

The reason for a barrier before is that the memory being accessed may
depend on a previous writel() hitting the device, so we need to ensure
proper ordering wrt. other writel()s.

I don't think we need a barrier after because these any future device
writes by the write[bwl]() accessors will have a barrier before them,
which will ensure proper ordering.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help