Re: [PATCH v2] mtd mxc_nand: use 32bit copy functions

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Tue, May 29, 2012 at 11:36:29AM +0200, Sascha Hauer wrote:
> On Tue, May 29, 2012 at 11:12:54AM +0200, Uwe Kleine-König wrote:
> > Hello,
> > 
> > On Tue, May 29, 2012 at 10:16:09AM +0200, Sascha Hauer wrote:
> > > The following commit changes the function used to copy from/to
> > > the hardware buffer to memcpy_[from|to]io. This does not work
> > > since the hardware cannot handle the byte accesses used by these
> > > functions. Instead of reverting this patch introduce 32bit
> > > correspondents of these functions.
> > Hmm, I didn't run an mtd test suite, but on mx27 it worked for me. IMHO
> > it's surprising that memcpy used to work, but memcpy_fromio doesn't. I
> > wouldn't expect a different semantic (apart from normal vs. __iomem
> > memory). And I wonder what will break when ARM's memcpy_fromio et al.
> > is optimized.
> 
> Have a look at the (ARM) implementation of memcpy_fromio:
> 
> void _memcpy_fromio(void *to, const volatile void __iomem *from, size_t count)
> {
> 	unsigned char *t = to;
> 	while (count) {
> 		count--;
> 		*t = readb(from);
> 		t++;
> 		from++;
> 	}
> }
> 
> Appearently this uses byte accesses which do not work on NFC SRAM,
> whereas memcpy uses optimized (so 32bit whenever possible) accesses.
> If someone would implement an optimized version of memcpy_fromio, it
> would work for the NFC aswell.
> 
> btw on i.MX27 byte accesses also do not work on NFC SRAM, so I doubt
> this worked for you.

And then when you ask for an odd alignment or an odd number of bytes...