[U-Boot] [RFC PATCH] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[U-Boot] [RFC PATCH] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.

Reading C99 6.7.3 8 and the comment 114) there, I think it is a bug of that
gcc version to ignore the volatile type qualifier used e.g. in __arch_getl().
Anyway, using a definition as in the kernel headers avoids such optimizations when
gcc 4.5.1 is used.

Maybe the headers as used in the current linux-kernel should be used,
but to avoid large changes, I've just added a small change to the current headers.

I haven't add the definitions which are using a memory barrier because I haven't found
a place in the kernel where they were actually enabled (CONFIG_ARM_DMA_MEM_BUFFERABLE).

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
 arch/arm/include/asm/io.h |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index ff1518e..3b6c1da 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -125,13 +125,16 @@ extern inline void __raw_readsl(unsigned int addr, void *data, int longlen)
 #define __raw_readw(a)			__arch_getw(a)
 #define __raw_readl(a)			__arch_getl(a)
 
-#define writeb(v,a)			__arch_putb(v,a)
-#define writew(v,a)			__arch_putw(v,a)
-#define writel(v,a)			__arch_putl(v,a)
+#define __iormb()		do { } while (0)
+#define __iowmb()		do { } while (0)
 
-#define readb(a)			__arch_getb(a)
-#define readw(a)			__arch_getw(a)
-#define readl(a)			__arch_getl(a)
+#define writeb(v,c)		({ __iowmb(); __arch_putb(v,c); })
+#define writew(v,c)		({ __iowmb(); __arch_putw(v,c); })
+#define writel(v,c)		({ __iowmb(); __arch_putl(v,c); })
+
+#define readb(c)		({ u8  __v = __arch_getb(c); __iormb(); __v; })
+#define readw(c)		({ u16 __v = __arch_getw(c); __iormb(); __v; })
+#define readl(c)		({ u32 __v = __arch_getl(c); __iormb(); __v; })
 
 /*
  * The compiler seems to be incapable of optimising constants
-- 
1.7.2.2

[U-Boot] [RFC PATCH] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

Hello,

Am -10.01.-28163 20:59, schrieb Alexander Holler:

> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
> avoid that as done in the kernel.

> ---
>   arch/arm/include/asm/io.h |   15 +++++++++------
>   1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index ff1518e..3b6c1da 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -125,13 +125,16 @@ extern inline void __raw_readsl(unsigned int addr, void *data, int longlen)
>   #define __raw_readw(a)			__arch_getw(a)
>   #define __raw_readl(a)			__arch_getl(a)
>
> -#define writeb(v,a)			__arch_putb(v,a)
> -#define writew(v,a)			__arch_putw(v,a)
> -#define writel(v,a)			__arch_putl(v,a)
> +#define __iormb()		do { } while (0)
> +#define __iowmb()		do { } while (0)
>
> -#define readb(a)			__arch_getb(a)
> -#define readw(a)			__arch_getw(a)
> -#define readl(a)			__arch_getl(a)
> +#define writeb(v,c)		({ __iowmb(); __arch_putb(v,c); })
> +#define writew(v,c)		({ __iowmb(); __arch_putw(v,c); })
> +#define writel(v,c)		({ __iowmb(); __arch_putl(v,c); })
> +
> +#define readb(c)		({ u8  __v = __arch_getb(c); __iormb(); __v; })
> +#define readw(c)		({ u16 __v = __arch_getw(c); __iormb(); __v; })
> +#define readl(c)		({ u32 __v = __arch_getl(c); __iormb(); __v; })
>
>   /*
>    * The compiler seems to be incapable of optimising constants

Sorry, but that patch doesn't work. My first version of that used 
__arch_putb and __arch_getb for all (instead of w and l), therefor the 
generated asm code looked (somewhat) correct and I've concluded wrongly 
that the compiler now doesn't do the wrong optimizations. But after I've 
changed that to use l and w, those (wrong) optimizations where back 
again and I haven't seen that.

Sorry, will look for another solution.

Regards,

Alexander