Hi,
rdos wrote:Brendan wrote:The ACPI specification says something like "For hardware that has decent/standardised enumeration (like PCI and USB), an OS uses the existing decent/standardised enumeration and doesn't use ACPI".
But PCI does not have decent enumeration since the address space supported by different PCI systems are not identical. Some PCIs will have the same device at many addresses because it doesn't decode everything. Also, it takes too long to check every possible PCI address at boot-time. That's why extracting available PCI addresses, and only checking them, from the PCI0 object in the ACPI-namespace would make sense.
"PCI configuration space" (what it contains, how it is accessed and how to traverse it to discover/enumerate all devices) is well standardised (although unfortunately some of those standards are behind a tall "pay wall"). The only thing not covered is devices behind a "PCI to LPC" or "PCI to ISA" bridge (and ACPI does include some information for legacy/non-PCI devices behind these bridges).
The only case of "same device at many addresses" that I can think of is ISA/legacy devices that aren't PCI (e.gh. behind a "PCI to LPC bridge"); although there may also be some issues with dodgy/borked bridges that don't handle 64-bit device properly.
If you're checking every possible "PCI address" (e.g. "for(bus = 0 to 255) { for(device = 0 to 31) { for(function = 0 to 7) { ... } } }") then you're doing it wrong. If you're doing it right (e.g. only checking buses that exist, and only checking for functions 1 to 7 if the device is a multi-function device), then if it takes too long it's likely that it's not PCI's fault.
For one example of what I meant, here's one paragraph from ACPI (the note in "3.4 Controlling Device Power" in ACPI revision 4.0):
Note:Other buses enumerate some devices on the main board. For example, PCI devices are reported through the standard PCI enumeration mechanisms. Power management of these devices is handled through their own bus specification (in this case, PCI). All other devices on the main board are handled through ACPI. Specifically, the ACPI table lists legacy devices that cannot be reported through their own bus specification, the root of each bus in the system, and devices that have additional power management or configuration options not covered by their own bus specification.
For another example, here's a paragraph from "3.7 Configuration and "Plug and Play" in ACPI revision 4.0:
ACPI is used primarily to enumerate and configure motherboard devices that do not have other hardware standards for enumeration and configuration. For example, PCI devices on the motherboard need not be enumerated by ACPI; Plug and Play information for these devices need not be included in the APCI Namespace. However, power management information and insertion/removal control for these devices can still appear in the namespace if the devices’ power management and/or insertion/removal is to be controlled by OSPM via ACPI-defined interfaces.
To be honest, I'm not too sure what the "_SB.PCIn" part of the ACPI name space is meant to be used for. It's not a replacement for PCI configuration space or PCI's enumeration; and looks like it's only an extension for things that can't be covered by PCI configuration space directly (like PCI hot-plug).
I also don't know much about Intel's ACPICA - it's possible that ACPICA includes PCI device enumeration even though it's not part of ACPI.
Cheers,
Brendan
