1 ACPI considerations for PCI host bridges 2 3The general rule is that the ACPI namespace should describe everything the 4OS might use unless there's another way for the OS to find it [1, 2]. 5 6For example, there's no standard hardware mechanism for enumerating PCI 7host bridges, so the ACPI namespace must describe each host bridge, the 8method for accessing PCI config space below it, the address space windows 9the host bridge forwards to PCI (using _CRS), and the routing of legacy 10INTx interrupts (using _PRT). 11 12PCI devices, which are below the host bridge, generally do not need to be 13described via ACPI. The OS can discover them via the standard PCI 14enumeration mechanism, using config accesses to discover and identify 15devices and read and size their BARs. However, ACPI may describe PCI 16devices if it provides power management or hotplug functionality for them 17or if the device has INTx interrupts connected by platform interrupt 18controllers and a _PRT is needed to describe those connections. 19 20ACPI resource description is done via _CRS objects of devices in the ACPI 21namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read 22_CRS and figure out what resource is being consumed even if it doesn't have 23a driver for the device [3]. That's important because it means an old OS 24can work correctly even on a system with new devices unknown to the OS. 25The new devices might not do anything, but the OS can at least make sure no 26resources conflict with them. 27 28Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for 29reserving address space. The static tables are for things the OS needs to 30know early in boot, before it can parse the ACPI namespace. If a new table 31is defined, an old OS needs to operate correctly even though it ignores the 32table. _CRS allows that because it is generic and understood by the old 33OS; a static table does not. 34 35If the OS is expected to manage a non-discoverable device described via 36ACPI, that device will have a specific _HID/_CID that tells the OS what 37driver to bind to it, and the _CRS tells the OS and the driver where the 38device's registers are. 39 40PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should 41describe all the address space they consume. This includes all the windows 42they forward down to the PCI bus, as well as registers of the host bridge 43itself that are not forwarded to PCI. The host bridge registers include 44things like secondary/subordinate bus registers that determine the bus 45range below the bridge, window registers that describe the apertures, etc. 46These are all device-specific, non-architected things, so the only way a 47PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain 48the device-specific details. The host bridge registers also include ECAM 49space, since it is consumed by the host bridge. 50 51ACPI defines a Consumer/Producer bit to distinguish the bridge registers 52("Consumer") from the bridge apertures ("Producer") [4, 5], but early 53BIOSes didn't use that bit correctly. The result is that the current ACPI 54spec defines Consumer/Producer only for the Extended Address Space 55descriptors; the bit should be ignored in the older QWord/DWord/Word 56Address Space descriptors. Consequently, OSes have to assume all 57QWord/DWord/Word descriptors are windows. 58 59Prior to the addition of Extended Address Space descriptors, the failure of 60Consumer/Producer meant there was no way to describe bridge registers in 61the PNP0A03/PNP0A08 device itself. The workaround was to describe the 62bridge registers (including ECAM space) in PNP0C02 catch-all devices [6]. 63With the exception of ECAM, the bridge register space is device-specific 64anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to 65know about it. 66 67New architectures should be able to use "Consumer" Extended Address Space 68descriptors in the PNP0A03 device for bridge registers, including ECAM, 69although a strict interpretation of [6] might prohibit this. Old x86 and 70ia64 kernels assume all address space descriptors, including "Consumer" 71Extended Address Space ones, are windows, so it would not be safe to 72describe bridge registers this way on those architectures. 73 74PNP0C02 "motherboard" devices are basically a catch-all. There's no 75programming model for them other than "don't use these resources for 76anything else." So a PNP0C02 _CRS should claim any address space that is 77(1) not claimed by _CRS under any other device object in the ACPI namespace 78and (2) should not be assigned by the OS to something else. 79 80The PCIe spec requires the Enhanced Configuration Access Method (ECAM) 81unless there's a standard firmware interface for config access, e.g., the 82ia64 SAL interface [7]. A host bridge consumes ECAM memory address space 83and converts memory accesses into PCI configuration accesses. The spec 84defines the ECAM address space layout and functionality; only the base of 85the address space is device-specific. An ACPI OS learns the base address 86from either the static MCFG table or a _CBA method in the PNP0A03 device. 87 88The MCFG table must describe the ECAM space of non-hot pluggable host 89bridges [8]. Since MCFG is a static table and can't be updated by hotplug, 90a _CBA method in the PNP0A03 device describes the ECAM space of a 91hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base 92address always corresponds to bus 0, even if the bus range below the bridge 93(which is reported via _CRS) doesn't start at 0. 94 95 96[1] ACPI 6.2, sec 6.1: 97 For any device that is on a non-enumerable type of bus (for example, an 98 ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI 99 system firmware must supply an _HID object ... for each device to 100 enable OSPM to do that. 101 102[2] ACPI 6.2, sec 3.7: 103 The OS enumerates motherboard devices simply by reading through the 104 ACPI Namespace looking for devices with hardware IDs. 105 106 Each device enumerated by ACPI includes ACPI-defined objects in the 107 ACPI Namespace that report the hardware resources the device could 108 occupy [_PRS], an object that reports the resources that are currently 109 used by the device [_CRS], and objects for configuring those resources 110 [_SRS]. The information is used by the Plug and Play OS (OSPM) to 111 configure the devices. 112 113[3] ACPI 6.2, sec 6.2: 114 OSPM uses device configuration objects to configure hardware resources 115 for devices enumerated via ACPI. Device configuration objects provide 116 information about current and possible resource requirements, the 117 relationship between shared resources, and methods for configuring 118 hardware resources. 119 120 When OSPM enumerates a device, it calls _PRS to determine the resource 121 requirements of the device. It may also call _CRS to find the current 122 resource settings for the device. Using this information, the Plug and 123 Play system determines what resources the device should consume and 124 sets those resources by calling the device’s _SRS control method. 125 126 In ACPI, devices can consume resources (for example, legacy keyboards), 127 provide resources (for example, a proprietary PCI bridge), or do both. 128 Unless otherwise specified, resources for a device are assumed to be 129 taken from the nearest matching resource above the device in the device 130 hierarchy. 131 132[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4: 133 QWord/DWord/Word Address Space Descriptor (.1, .2, .3) 134 General Flags: Bit [0] Ignored 135 136 Extended Address Space Descriptor (.4) 137 General Flags: Bit [0] Consumer/Producer: 138 1–This device consumes this resource 139 0–This device produces and consumes this resource 140 141[5] ACPI 6.2, sec 19.6.43: 142 ResourceUsage specifies whether the Memory range is consumed by 143 this device (ResourceConsumer) or passed on to child devices 144 (ResourceProducer). If nothing is specified, then 145 ResourceConsumer is assumed. 146 147[6] PCI Firmware 3.2, sec 4.1.2: 148 If the operating system does not natively comprehend reserving the 149 MMCFG region, the MMCFG region must be reserved by firmware. The 150 address range reported in the MCFG table or by _CBA method (see Section 151 4.1.3) must be reserved by declaring a motherboard resource. For most 152 systems, the motherboard resource would appear at the root of the ACPI 153 namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and 154 the resources in this case should not be claimed in the root PCI bus’s 155 _CRS. The resources can optionally be returned in Int15 E820 or 156 EFIGetMemoryMap as reserved memory but must always be reported through 157 ACPI as a motherboard resource. 158 159[7] PCI Express 4.0, sec 7.2.2: 160 For systems that are PC-compatible, or that do not implement a 161 processor-architecture-specific firmware interface standard that allows 162 access to the Configuration Space, the ECAM is required as defined in 163 this section. 164 165[8] PCI Firmware 3.2, sec 4.1.2: 166 The MCFG table is an ACPI table that is used to communicate the base 167 addresses corresponding to the non-hot removable PCI Segment Groups 168 range within a PCI Segment Group available to the operating system at 169 boot. This is required for the PC-compatible systems. 170 171 The MCFG table is only used to communicate the base addresses 172 corresponding to the PCI Segment Groups available to the system at 173 boot. 174 175[9] PCI Firmware 3.2, sec 4.1.3: 176 The _CBA (Memory mapped Configuration Base Address) control method is 177 an optional ACPI object that returns the 64-bit memory mapped 178 configuration base address for the hot plug capable host bridge. The 179 base address returned by _CBA is processor-relative address. The _CBA 180 control method evaluates to an Integer. 181 182 This control method appears under a host bridge object. When the _CBA 183 method appears under an active host bridge object, the operating system 184 evaluates this structure to identify the memory mapped configuration 185 base address corresponding to the PCI Segment Group for the bus number 186 range specified in _CRS method. An ACPI name space object that contains 187 the _CBA method must also contain a corresponding _SEG method. 188
