Messages in this thread |  | | | Date | Thu, 23 Jun 2005 19:22:08 +0100 (BST) | | From | "Maciej W. Rozycki" <> | | Subject | Re: PATCH: IDE - sensible probing for PCI systems |
| |
On Tue, 21 Jun 2005, Alan Cox wrote:
> > How is the range defined -- is there a way for us to find it? I'd assume > > in the absence of a PCI-ISA or PCI-EISA bridge all I/O port addresses > > belong to PCI. Otherwise the usual rule of "(addr & 0x300) == 0" applies. > > Perhaps with the addition of "(addr & ~0xff) != 0" for safety as junk I/O > > is often not recorded properly in BARs, sigh... > > No the low addresses belong to the chipset and motherboard. There is
Well, that doesn't mean they can't be properly reported in a BAR.
Besides, does a modern i386 really require them? DOS compatibility is no longer an issue for commodity hardware and the ISA bridge is gone. Apparently the only legacy device still not replaced by anything else is the RTC, which is rather surprising as there seems to be a lot of reasonable alternatives for I2C available these days and i386 boxes have had I2C for quite a while now.
> also magic then for video and IDE legacy port ranges. I suspect your
Both IDE and video are distinct PCI devices these days, so there is no need for them to hide their decoded address ranges. I've thought that has been sorted out.
> mips boxen might be a lot cleaner than the PC world.
They are certainly cleaner, but if a lot, it depends on whether an (E)ISA bridge is there somewhere or not. E.g. some PCI-ISA bridges positively decode some memory address ranges unconditionally which results in the corresponding range of RAM being unreachable from PCI. And if there is no (E)ISA bridge, there may still be traces of legacy, like P2P bridges with an implicit special treatment of certain address ranges that traditionally used to be used for ISA. Or APIC interrupt codes in messages sent over HT.
Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |