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 <ang...@sysam.it> > > --- > > 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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
