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

[Sanjay Tandel]

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.

>       Arnd

Thanks,
Sanjay