summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica
diff options
context:
space:
mode:
authorjhb <jhb@FreeBSD.org>2002-11-22 18:11:13 +0000
committerjhb <jhb@FreeBSD.org>2002-11-22 18:11:13 +0000
commit5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f (patch)
tree9d22c7407abc0aec2196019c2472a159313b86a5 /sys/dev/acpica
parentc532e9c1042c4729b06bc8853da88a03a269625e (diff)
downloadFreeBSD-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/dev/acpica')
-rw-r--r--sys/dev/acpica/acpi_pcib_acpi.c59
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.
*/
OpenPOWER on IntegriCloud