summaryrefslogtreecommitdiffstats
path: root/sys/i386/include/nexusvar.h
Commit message (Collapse)AuthorAgeFilesLines
* Rework how the nexus(4) device works on x86 to better handle the idea ofjhb2008-03-131-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@
* Update the nexus driver for the addition of the legacy driver:jhb2002-09-231-43/+0
| | | | | | | | | - nexus no longer has PCI bridges as direct children, so the PCI bus ivar is no longer used and is removed. - Don't attach default EISA, ISA, or MCA busses. Instead, if we do not have an acpi0 device after bus_generic_probe(), add a legacy0 child device. - Remove machine/nexusvar.h.
* Use the __BUS_ACCESSOR macro for NEXUS_ACCESSORmux2002-08-201-14/+2
| | | | | | instead of rolling our own implementation. Reviewed by: tmm
* Get out the roto-rooter and clean up the abuse of nexus ivars by thepeter2000-09-281-0/+55
i386/isa/pcibus.c. This gets -current running again on multiple host->pci machines after the most recent nexus commits. I had discussed this with Mike Smith, but ended up doing it slightly differently to what we discussed as it turned out cleaner this way. Mike was suggesting creating a new resource (SYS_RES_PCIBUS) or something and using *_[gs]et_resource(), but IMHO that wasn't ideal as SYS_RES_* is meant to be a global platform property, not a quirk of a given implementation. This does use the ivar methods but does so properly. It also now prints the physical pci bus that a host->pci bridge (pcib) corresponds to.
OpenPOWER on IntegriCloud