> > 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.
Yes, the PCI bus is defined to be little endian.
>
> > 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?
>
After a long discussion with a friend of mine who's done a big of kernel
hacking (Bibek Sahu) who has an Alpha, we decided that we need to know
exactly *what* ioremap is supposed to do. Is it just supposed to take a
physical address and map it into a usable vitual address, or should it
also take care of MMIO offsets, etc?
Shouldn't ioremap also take care of various processor-bus to pci bus
mappings?? I have had to hard code the addresses of my Matrox card to get
it to work since the what the processor sees as 0xF0000000, the PCI bus
(and pci_read_config_dword(pdev, MEMORY_BASE_0) ) see the same access as
0x30000000. If ioremap doesn't take care of this, what is supposed to? Do
we need a phys_to_bus or something? And if a driver is to be
cross-platform, it shouldn't have to know about messy stuff like that.
Some (older?) Alpha's can't even support real memory mapped IO and *must*
use readl, writel, etc.. However, All PPC's I'm aware of support mmio,
along with Intel, correct?
--------------------------------------------------------------------------
| Troy Benjegerdes | troybenj@iastate.edu | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
-
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/