Re: PATCH: IDE - sensible probing for PCI systems
From: Maciej W. Rozycki
Date: Thu Jun 23 2005 - 13:24:24 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/