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

Russell King - ARM Linux linux at arm.linux.org.uk
Fri Sep 28 10:29:14 EDT 2012


On Fri, Sep 28, 2012 at 03:13:42PM +0100, Catalin Marinas wrote:
> On 28 September 2012 14:36, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Thursday 27 September 2012, Russell King wrote:
> >> +#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.



More information about the linux-arm-kernel mailing list