On 22.12.2010 09:02, Wolfgang Denk wrote:
> Dear Alexander Holler,
>
> In message<1292711230-3234-1-git-send-email-hol...@ahsoftware.de> you wrote:
>> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
>> avoid that as done in the kernel.
> ...
>> +#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); })
>
> http://www.codesourcery.com/archives/arm-gnu/msg03990.html explains
> why this construct is causing errors in cases where an additional read
> from the address is unsupported.
Just for the record:
The trick is to ensure that the __arch_putx() containing the volatile
is not the last statement in the GCC statement-expression. So, using
something like
#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); v;})
(note the additional 'v;') should result in correct code, too.
The patches sent by Wolfgang and Alexander using
#define writeb(v,c) do { __iowmb(); __arch_putb(v,c); } while (0)
do the same with a slightly different syntax, so these patches are
fine, too.
Thanks
Dirk
> Can you please try the following patch instead?
>
> -------------------------------------------------------------------------
>
>> From 4672bbddaf8ce7e17a99ba737782cc527d46e5eb Mon Sep 17 00:00:00 2001
> From: Alexander Holler<hol...@ahsoftware.de>
> Date: Sat, 18 Dec 2010 23:27:10 +0100
> Subject: [PATCH] ARM: Avoid compiler optimization for readb, writeb and
> friends.
>
> 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.
>
> Signed-off-by: Alexander Holler<hol...@ahsoftware.de>
> Signed-off-by: Wolfgang Denk<w...@denx.de>
> ---
> arch/arm/include/asm/io.h | 32 ++++++++++++++++++++------------
> 1 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index ff1518e..647503a 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -117,21 +117,29 @@ extern inline void __raw_readsl(unsigned int addr, void
> *data, int longlen)
> *buf++ = __arch_getl(addr);
> }
>
> -#define __raw_writeb(v,a) __arch_putb(v,a)
> -#define __raw_writew(v,a) __arch_putw(v,a)
> -#define __raw_writel(v,a) __arch_putl(v,a)
> +#define __raw_writeb(v,a) __arch_putb(v,a)
> +#define __raw_writew(v,a) __arch_putw(v,a)
> +#define __raw_writel(v,a) __arch_putl(v,a)
>
> -#define __raw_readb(a) __arch_getb(a)
> -#define __raw_readw(a) __arch_getw(a)
> -#define __raw_readl(a) __arch_getl(a)
> +#define __raw_readb(a) __arch_getb(a)
> +#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)
> +/*
> + * TODO: The kernel offers some more advanced versions of barriers, it might
> + * have some advantages to use them instead of the simple one here.
> + */
> +#define dmb() __asm__ __volatile__ ("" : : : "memory")
> +#define __iormb() dmb()
> +#define __iowmb() dmb()
> +
> +#define writeb(v,c) do { __iowmb(); __arch_putb(v,c); } while (0)
> +#define writew(v,c) do { __iowmb(); __arch_putw(v,c); } while (0)
> +#define writel(v,c) do { __iowmb(); __arch_putl(v,c); } while (0)
>
> -#define readb(a) __arch_getb(a)
> -#define readw(a) __arch_getw(a)
> -#define readl(a) __arch_getl(a)
> +#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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
