You need to take this up with the PPC guys. Presumably they had a reason for
this; I suspect it's because the PCI bus is naturally little endian but I
could be wrong.
> to Matrox devices. They (Matroxes) know about PPC and expect bytes
> in big-endian ordering. So I cannot use writel/readl on PPC.
Can you not switch the Matrox to little-endian mode?
> On __arm__ (Arm does not have PCI, so no problem) it copies memory
> byte-by-byte, so it is completely unusable if hardware expects only
> 32-bit (or 64-bit) accesses :-(
Actually ARM machines do have PCI. If your hardware is expecting particular
types of access then you shouldn't be using the memcpy() functions in any
case. Readl() and writel() do accesses 32 bits at a time on ARM systems as
you would expect (the ARM has no support for 64-bit operation). This possibly
isn't the case for some of the Acorn architectures where a lot of the I/O
stuff is somewhat peculiar, but you probably don't want to look at those in
any case.
> a) every driver should be fixed to use ioremap
Yes, this is obviously the goal. A lot of PC drivers however have various
historical assumptions about the memory map encoded into them.
>#ifdef __alpha__
>#define mga_readl(x) readl(x)
>#else
>#define mga_readl(x) (*(volatile u_int32_t*)(x))
>#endif
Surely the oddball case is the PPC and not the Alpha?
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/