[PATCH] map-ram chip driver: 16-bit block transfer

[Boris Brezillon]

Le Fri, 11 Aug 2017 18:42:44 -0500,
Sanjay Tandel <sanjay.tandel at rockwellcollins.com> a écrit :

> On Fri, Aug 11, 2017 at 4:30 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Fri, Aug 11, 2017 at 11:03 PM, Sanjay Tandel
> > <sanjay.tandel at rockwellcollins.com> wrote:  
> >> On Fri, Aug 11, 2017 at 2:41 PM, Arnd Bergmann <arnd at arndb.de> wrote:  
> >>> On Fri, Aug 11, 2017 at 6:50 PM, Sanjay Tandel
> >>> On almost all ARM platforms, it would use 32-bit accesses these days. On what
> >>> kernel version, ARM platform and endianess do you see memcpy_toio() use 8-bit
> >>> access?
> >>>  
> >>
> >> We use version 4.1.8 with Freescale LS1021A( cortex-a7 core, little-endian).
> >> With the newer versions of kernel also, I can see same 8-bit
> >> implementation for 32-bit ARM arch.  
> >
> > I see. Commit 7ddfe625cbc1 ("ARM: optimize
> > memset_io()/memcpy_fromio()/memcpy_toio()")
> > was merged in linux-4.2 and changed this to use mostly 32-bit accesses and a
> > bug in it fixed in commit 1bd46782d08b ("ARM: avoid unwanted GCC
> > memset()/memcpy() optimisations for IO variants").
> >
> >  
> >> BTW, for other arch also memcpy_toio()  uses combination of  32-bit(or
> >> 64-bit) and 8-bit accesses,
> >> which may not work here.Because we need all accesses to be of same
> >> size(bank-width).  
> >
> > Could you try with a newer kernel or with the 7ddfe625cbc1/1bd46782d08b
> > commits backported to see if that works for you though? At the very least that
> > should impact the description of the patch we end up applying, since your
> > current text no longer matches what the kernel does.
> >  
> 
> I tested back-porting commits 7ddfe625cbc1/1bd46782d08b,
> but that didn't work for me.
> 
> Before, it used to corrupt every 2nd byte(2nd,4rth,6th ... upto N) in memory,
> with memcpy_toio() using 8-bit accesses for our 16-bit chip.
> 
> Now, with backporting 7ddfe625cbc1/1bd46782d08b, it corrupts (N + 1)th byte
> in memory, when I tried to write N number of bytes (where N is not aligned to
> 4-byte boundary).That means, it still tries 8-bit access for last odd byte and
> ends up corrupting next byte.

Yes, that's expected as the size is not 16bit aligned.

Anyway, I read the whole thread again and AFAIU memcpy_to/fromio() is
only appropriate if the bus controller the device is connected to is
smart enough to hide all alignment problems to its users.

Don't know what controller is causing trouble here, but you should
probably have a dedicated driver (if that's not already the case) that
overloads the ->copy_from()/->copy_to() methods to do the right thing
for your memory controller.