Re: [PATCH v3 2/2] m68k: mmu: fix IO access endianness for ColdFire family

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 02, 2018 at 09:28:57AM +1000, Greg Ungerer wrote:
Hi Greg,

Hi Angelo,

On 01/03/18 22:32, Angelo Dureghello wrote:
This patch fixes IO access endianness, that should be big endian.
If any little endian peripheral may be connected, bytes should
be swapped in hardware.

I am not sure I follow your meaning here. In many cases peripheral
devices will be hooked up and they are inherently little endian
but there is no hardware in between that will translate the endian.
It is just something that has to be dealt with at the software driver
level.

So do you need to make this change for specific devices you are
working with?


Ok, well, i add some story to this patch. I was stuck from months
since  kernel was hanging silently when SPI driver was enabled in
conjunction with mmu enbabled (no issues in spi + nommu).
 
After hard debugging, i finally found the issue to be related to
a wrong ioremap, and, together (so a double issue), peripheral
registers was wrongly accessed as "little" endian.

This was resulting in never getting any reply from SPI device, and
kernel hanging silently in a wait loop. So, in mmu mode (io_mm.h),
the mcf5441x IO peripheral address area (0xe0000000 to 0xffffffff)
needs to be accessed as "big endian".

So to have mmu working on mcf5441x both patches are needed.

As suggester by Geert, i isolated ioread/write to be big endian
for mcf5441x *only*. 


About my comment on endianness: some time ago i had to connect 
"amcore" cpu (big endian) with dm9000 IO peripheral (little endian).
Software swap was not accepted, and i was informed that the proper and
recommended way to go, even if a sw conversion is of course possible,
was to swap endianness in hardware. So i had to modify my board design 
swapping byte wires, and issue new pcb prototypes. There should be a
tracked discussion about this searching about dm9000 endianness here
or in the net mailing list.

I can modify that comment if it results wrong or too hard.

I have my system back working now with new drivers and mmu enabled.

(P.S.; i remember you was using an elf toolchain for mmu, do you have
any link in case ? :) 

I don't see that the M5441x parts are really special or different
from any of the other ColdFire (or even traditional m68k) devices
we currently support.

Regards
Greg



Regards,
Angelo

---
Changes from v2:
- patch reduced form 3/3 to 2/2
- isolated big endian IO read/write[w,l] to mcf5441x

Signed-off-by: Angelo Dureghello <angelo@xxxxxxxx>
---
 arch/m68k/include/asm/io_mm.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index ed5333e87879..a1a0f870b61b 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -444,13 +444,29 @@ static inline void isa_delay(void)
  */
 #define readb(addr)      in_8(addr)
 #define writeb(val,addr) out_8((addr),(val))
+#ifdef CONFIG_M5441x
+/*
+ * mcf5441x only accesses IO/peripheral internal memory.
+ */
+#define readw(addr)		in_be16(addr)
+#define writew(val, addr)	out_be16((addr), (val))
+#else
 #define readw(addr)      in_le16(addr)
 #define writew(val,addr) out_le16((addr),(val))
+#endif
 
 #endif /* !CONFIG_ISA && !CONFIG_ATARI_ROM_ISA */
 
+#ifdef CONFIG_M5441x
+/*
+ * mcf5441x only accesses IO/peripheral internal memory.
+ */
+#define readl(addr)		in_be32(addr)
+#define writel(val, addr)	out_be32((addr), (val))
+#else
 #define readl(addr)      in_le32(addr)
 #define writel(val,addr) out_le32((addr),(val))
+#endif
 
 #define readsb(port, buf, nr)     raw_insb((port), (u8 *)(buf), (nr))
 #define readsw(port, buf, nr)     raw_insw((port), (u16 *)(buf), (nr))


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux