diff options
author | jhb <jhb@FreeBSD.org> | 2002-11-22 18:11:13 +0000 |
---|---|---|
committer | jhb <jhb@FreeBSD.org> | 2002-11-22 18:11:13 +0000 |
commit | 5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f (patch) | |
tree | 9d22c7407abc0aec2196019c2472a159313b86a5 /sys | |
parent | c532e9c1042c4729b06bc8853da88a03a269625e (diff) | |
download | FreeBSD-src-5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f.zip FreeBSD-src-5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f.tar.gz |
According to the ACPI spec, the bus number of the child PCI bus of a host
to PCI bridge can be read be evaluating the _BBN method of the host to PCI
device. Unfortunately, there appear to be some lazy/ignorant/moronic/
whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in
the system. On a system with a single host to PCI bridge this is not a
problem as the child bus of that single bridge will be bus 0 anyway.
However, on systems with multiple host to PCI bridges and l/i/m/w BIOS
writers this is a major problem resulting in all but the first host to
PCI bridge failing to attach. So, this adds a workaround.
If the _BBN of a host to PCI bridge is zero and pcib0 already exists
and is not us, the we use _ADR to look up our PCI function and slot
(we currently assume we are on bus 0) and use that to call
host_pcib_get_busno() to try and extract our bus number from config
registers on the host to PCI bridge device. If that fails, then we make
an evil assumption that ACPI's _SB_ namespace lays out the host to PCI
bridges in ascending order and use our pcib unit number as our bus
number.
Approved by: re
Diffstat (limited to 'sys')
-rw-r--r-- | sys/dev/acpica/acpi_pcib_acpi.c | 59 |
1 files changed, 52 insertions, 7 deletions
diff --git a/sys/dev/acpica/acpi_pcib_acpi.c b/sys/dev/acpica/acpi_pcib_acpi.c index 0f70905..31e4c44 100644 --- a/sys/dev/acpica/acpi_pcib_acpi.c +++ b/sys/dev/acpica/acpi_pcib_acpi.c @@ -132,6 +132,8 @@ acpi_pcib_acpi_attach(device_t dev) { struct acpi_hpcib_softc *sc; ACPI_STATUS status; + uint addr, slot, func, busok; + uint8_t busno; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -140,7 +142,7 @@ acpi_pcib_acpi_attach(device_t dev) sc->ap_handle = acpi_get_handle(dev); /* - * Get our base bus number by evaluating _BBN. If that doesn't work, try _ADR. + * Get our base bus number by evaluating _BBN. * If this doesn't work, we assume we're bus number 0. * * XXX note that it may also not exist in the case where we are @@ -151,24 +153,67 @@ acpi_pcib_acpi_attach(device_t dev) * default PCI configuration space handlers can deal with this bus, * we should attach our own handler. * XXX invoke _REG on this for the PCI config space address space? + * XXX It seems many BIOS's with multiple Host-PCI bridges do not set + * _BBN correctly. They set _BBN to zero for all bridges. Thus, + * if _BBN is zero and pcib0 already exists, we try to read our + * bus number from the configuration registers at address _ADR. */ - if (ACPI_FAILURE(status = acpi_EvaluateInteger(sc->ap_handle, "_BBN", &sc->ap_bus))) { + status = acpi_EvaluateInteger(sc->ap_handle, "_BBN", &sc->ap_bus); + if (ACPI_FAILURE(status)) { if (status != AE_NOT_FOUND) { - device_printf(dev, "could not evaluate _BBN - %s\n", AcpiFormatException(status)); + device_printf(dev, "could not evaluate _BBN - %s\n", + AcpiFormatException(status)); return_VALUE(ENXIO); } - if (ACPI_FAILURE(status = acpi_EvaluateInteger(sc->ap_handle, "_ADR", &sc->ap_bus))) { + } else { + /* if it's not found, assume 0 */ + sc->ap_bus = 0; + } + + /* + * If the bus is zero and pcib0 already exists, read the bus number + * via PCI config space. + */ + busok = 1; + if (sc->ap_bus == 0 && devclass_get_device(pcib_devclass, 0) != dev) { + status = acpi_EvaluateInteger(sc->ap_handle, "_ADR", &addr); + if (ACPI_FAILURE(status)) { if (status != AE_NOT_FOUND) { - device_printf(dev, "could not evaluate _ADR - %s\n", AcpiFormatException(status)); + device_printf(dev, "could not evaluate _ADR - %s\n", + AcpiFormatException(status)); return_VALUE(ENXIO); + } else { + device_printf(dev, "could not determine config space address\n"); + busok = 0; } } else { - /* if it's not found, assume 0 */ - sc->ap_bus = 0; + /* XXX: We assume bus 0. */ + slot = addr >> 16; + func = addr & 0xffff; + if (bootverbose) + device_printf(dev, "reading config registers from 0:%d:%d\n", + slot, func); + if (host_pcib_get_busno(pci_cfgregread, 0, slot, func, &busno) == 0) { + device_printf(dev, "could not read bus number from config space\n"); + busok = 0; + } else { + sc->ap_bus = busno; + } } } /* + * If nothing else worked, hope that ACPI at least lays out the + * host-PCI bridges in order and that as a result our unit number + * is actually our bus number. There are several reasons this + * might not be true. + */ + if (busok == 0) { + sc->ap_bus = device_get_unit(dev); + device_printf(dev, "trying bus number %d\n", sc->ap_bus); + } + + /* * Get our segment number by evaluating _SEG * It's OK for this to not exist. */ |