Messages in this thread | | | Subject | Re: Accessing MMIO PCI space - crossplatform | Date | Thu, 12 Nov 1998 22:07:34 +0100 | From | Philip Blundell <> |
| |
> 2) they do not work at all on PPC because of they swap bytes to little > endian format. While it is (I'm not too much sure) probably correct
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/
| |