> Could you enlighten my very naive understanding of things about PCI/ISA > IO space? On x86, I seem to understand this is the separate address > space accessed by the special in/out CPU instructions. Are there ARM > platforms with the same sort of things?
An x86 processor has two address spaces A memory space An I/O space They are both visible to the PCI bus and both transaction types are present on the bus and distinct. > As far as I understand, on my ARM Marvell system, everything is > memory-mapped, so there isn't such a separate PCI/ISA IO space. There is if you ask the PCI bridge or beyond. > Therefore, why would I need to "select HAVE_IOPORT" simply to be able > to build libata-sff.c, that is used for PCI drivers that work fine with > purely memory-mapped registers? Because the drivers talk to the hardware beyond the bridge which knows the difference. So on x86 we have inb(0xf00); generates an I/O transaction on the PCI bus for I/O 0xf00 *0xf00 generates a memory transacion on the PCI bus for memory 0xf00 and the two are *not* the same thing or address On many other platforms we have inb(0xf00) actually produces the equivalent of (*io_window+0xf00) which the PCI bridge turns into an I/O transaction for 0xf00 (and for the out case may have an explicit barrier needed to get the I/O ordering rules) while *0xf00 gets turned by the bridge into a memory transaction for 0xf00 The "no I/O space" case really applies to things like the S/390 mainframe which simply have no such concept on the system or the devices. In the ARM case the bus has an I/O space and the bridge glues the processors simpler model to the bridge model. For compatibility reasons (so you an boot old software) the PCI bus also has some automatic magic mappings in I/O space, and a lot of LPC bus devices also have magic I/O mappings. For example a SATA controller in compatibility mode appears at a specified I/O address on the bus and is always on a specific IRQ (matching the old ISA PC mappings which map the old ISA MFM controller mappings whose offsets map compatiblity to the register mappings for the WD MFM controller used on the PC/AT) In PC space this stuff is important and it's why up until Windows 7 era PC hardware you can boot DOS, as well as being why you can have one generic kernel for almost any PC hardware instead of the one per board problem some other platforms have. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/