Messages in this thread | | | Date | Fri, 13 Nov 1998 21:03:11 -0600 (CST) | From | Troy Benjegerdes <> | Subject | Re: Accessing MMIO PCI space - crossplatform |
| |
On Thu, 12 Nov 1998, Philip Blundell wrote:
> > 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/
| |