Re: [PATCH] arc: use little endian accesses

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-03-10 at 05:05 +-0000, Vineet Gupta wrote:
+AD4- +-CC Noam
+AD4- 
+AD4- On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
+AD4- +AD4- 
+AD4- +AD4- Memory access primitives should use cpu+AF8-to+AF8-le16, cpu+AF8-to+AF8-le32, le16+AF8-to+AF8-cpu
+AD4- +AD4- and le32+AF8-to+AF8-cpu because it is not really guaranteed that drivers handles
+AD4- +AD4- any ordering themselves.
+AD4- That is the driver issue. readxx as API simply returns data in native endianness.
+AD4- We've had EZChip running big endian and so far and they didn't need this change.

Let me disagree with you here.
See what is said in +ACI-include/asm-generic/io.h+ACI-:
----------------------+AD4-8---------------------
/+ACo-
+AKAAKg- +AF8AXw-raw+AF8Aew-read,write+AH0Aew-b,w,l,q+AH0-() access memory in native endianness.
+AKAAKg-
+AKAAKg- On some architectures memory mapped IO needs to be accessed differently.
+AKAAKg- On the simple architectures, we just read/write the memory location
+AKAAKg- directly.
+AKAAKg-/

...

/+ACo-
+AKAAKg- +AHs-read,write+AH0Aew-b,w,l,q+AH0-() access little endian memory and return result in
+AKAAKg- native endianness.
+AKAAKg-/
----------------------+AD4-8---------------------

And that's an implementation we have for ARC:
----------------------+AD4-8---------------------
+ACM-define readb(c)		(+AHs- u8+AKAAoABfAF8-v +AD0- readb+AF8-relaxed(c)+ADs- +AF8AXw-iormb()+ADs- +AF8AXw-v+ADs- +AH0-)
+ACM-define readw(c)		(+AHs- u16 +AF8AXw-v +AD0- readw+AF8-relaxed(c)+ADs- +AF8AXw-iormb()+ADs- +AF8AXw-v+ADs- +AH0-)
+ACM-define readl(c)		(+AHs- u32 +AF8AXw-v +AD0- readl+AF8-relaxed(c)+ADs- +AF8AXw-iormb()+ADs- +AF8AXw-v+ADs- +AH0-)

+ACM-define writeb(v,c)		(+AHs- +AF8AXw-iowmb()+ADs- writeb+AF8-relaxed(v,c)+ADs- +AH0-)
+ACM-define writew(v,c)		(+AHs- +AF8AXw-iowmb()+ADs- writew+AF8-relaxed(v,c)+ADs- +AH0-)
+ACM-define writel(v,c)		(+AHs- +AF8AXw-iowmb()+ADs- writel+AF8-relaxed(v,c)+ADs- +AH0-)

/+ACo-
+AKAAKg- Relaxed API for drivers which can handle any ordering themselves
+AKAAKg-/
+ACM-define readb+AF8-relaxed(c)	+AF8AXw-raw+AF8-readb(c)
+ACM-define readw+AF8-relaxed(c)	+AF8AXw-raw+AF8-readw(c)
+ACM-define readl+AF8-relaxed(c)	+AF8AXw-raw+AF8-readl(c)

+ACM-define writeb+AF8-relaxed(v,c)	+AF8AXw-raw+AF8-writeb(v,c)
+ACM-define writew+AF8-relaxed(v,c)	+AF8AXw-raw+AF8-writew(v,c)
+ACM-define writel+AF8-relaxed(v,c)	+AF8AXw-raw+AF8-writel(v,c)
----------------------+AD4-8---------------------

Which is effectively (related to endianess discussion):
----------------------+AD4-8---------------------
+ACM-define readX(c)	+AF8AXw-raw+AF8-readX(c)
+ACM-define writeX(v,c)	+AF8AXw-raw+AF8-writeX(v,c)
----------------------+AD4-8---------------------

That looks IMHO incorrect if we read API description in +ACI-include/asm-generic/io.h+ACI-.
BTW description of +AHs-read,write+AH0Aew-b,w,l,q+AH0-() is a bit misleading in part saying
+ACI-... and return result in +AF8AXw-native+AF8-endianness+AF8AXwAi-.

But real implementation of +AHs-read,write+AH0Aew-b,w,l,q+AH0-() in +ACI-include/asm-generic/io.h+ACI-
really shows what was meant - note+AKAAXwBf-leXX+AF8-to+AF8-cpu() and+AKA-cpu+AF8-to+AF8-leXX are used.

+AD4- +AD4- 
+AD4- +AD4- For example, serial port driver doesn't work when kernel is build for
+AD4- +AD4- arc big endian architecture.
+AD4- Last I tested Big Endian on SDP with 8250 part +- 8250 driver it was working fine.
+AD4- I presume this is the systemC model for device and standard 8250 driver and very
+AD4- likely the model is not fixed endian or something.

Model is indeed little-endian. We build it only once and than changing
only +ACI-nsim+AF8-isa+AF8-big+AF8-endian+ACI- property (which changes only CPU core endianess) may use
it equally well with little- and big-endian builds of Linux kernel.

-Alexey