]>
Commit | Line | Data |
---|---|---|
39a212ad BH |
1 | ACPI considerations for PCI host bridges |
2 | ||
3 | The general rule is that the ACPI namespace should describe everything the | |
4 | OS might use unless there's another way for the OS to find it [1, 2]. | |
5 | ||
6 | For example, there's no standard hardware mechanism for enumerating PCI | |
7 | host bridges, so the ACPI namespace must describe each host bridge, the | |
8 | method for accessing PCI config space below it, the address space windows | |
9 | the host bridge forwards to PCI (using _CRS), and the routing of legacy | |
10 | INTx interrupts (using _PRT). | |
11 | ||
12 | PCI devices, which are below the host bridge, generally do not need to be | |
13 | described via ACPI. The OS can discover them via the standard PCI | |
14 | enumeration mechanism, using config accesses to discover and identify | |
15 | devices and read and size their BARs. However, ACPI may describe PCI | |
16 | devices if it provides power management or hotplug functionality for them | |
17 | or if the device has INTx interrupts connected by platform interrupt | |
18 | controllers and a _PRT is needed to describe those connections. | |
19 | ||
20 | ACPI resource description is done via _CRS objects of devices in the ACPI | |
21 | namespace [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 | |
23 | a driver for the device [3]. That's important because it means an old OS | |
24 | can work correctly even on a system with new devices unknown to the OS. | |
25 | The new devices might not do anything, but the OS can at least make sure no | |
26 | resources conflict with them. | |
27 | ||
28 | Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for | |
29 | reserving address space. The static tables are for things the OS needs to | |
30 | know early in boot, before it can parse the ACPI namespace. If a new table | |
31 | is defined, an old OS needs to operate correctly even though it ignores the | |
32 | table. _CRS allows that because it is generic and understood by the old | |
33 | OS; a static table does not. | |
34 | ||
35 | If the OS is expected to manage a non-discoverable device described via | |
36 | ACPI, that device will have a specific _HID/_CID that tells the OS what | |
37 | driver to bind to it, and the _CRS tells the OS and the driver where the | |
38 | device's registers are. | |
39 | ||
40 | PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should | |
41 | describe all the address space they consume. This includes all the windows | |
42 | they forward down to the PCI bus, as well as registers of the host bridge | |
43 | itself that are not forwarded to PCI. The host bridge registers include | |
44 | things like secondary/subordinate bus registers that determine the bus | |
45 | range below the bridge, window registers that describe the apertures, etc. | |
46 | These are all device-specific, non-architected things, so the only way a | |
47 | PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain | |
48 | the device-specific details. The host bridge registers also include ECAM | |
49 | space, since it is consumed by the host bridge. | |
50 | ||
51 | ACPI defines a Consumer/Producer bit to distinguish the bridge registers | |
52 | ("Consumer") from the bridge apertures ("Producer") [4, 5], but early | |
53 | BIOSes didn't use that bit correctly. The result is that the current ACPI | |
54 | spec defines Consumer/Producer only for the Extended Address Space | |
55 | descriptors; the bit should be ignored in the older QWord/DWord/Word | |
56 | Address Space descriptors. Consequently, OSes have to assume all | |
57 | QWord/DWord/Word descriptors are windows. | |
58 | ||
59 | Prior to the addition of Extended Address Space descriptors, the failure of | |
60 | Consumer/Producer meant there was no way to describe bridge registers in | |
61 | the PNP0A03/PNP0A08 device itself. The workaround was to describe the | |
62 | bridge registers (including ECAM space) in PNP0C02 catch-all devices [6]. | |
63 | With the exception of ECAM, the bridge register space is device-specific | |
64 | anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to | |
65 | know about it. | |
66 | ||
67 | New architectures should be able to use "Consumer" Extended Address Space | |
68 | descriptors in the PNP0A03 device for bridge registers, including ECAM, | |
69 | although a strict interpretation of [6] might prohibit this. Old x86 and | |
70 | ia64 kernels assume all address space descriptors, including "Consumer" | |
71 | Extended Address Space ones, are windows, so it would not be safe to | |
72 | describe bridge registers this way on those architectures. | |
73 | ||
74 | PNP0C02 "motherboard" devices are basically a catch-all. There's no | |
75 | programming model for them other than "don't use these resources for | |
76 | anything 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 | |
78 | and (2) should not be assigned by the OS to something else. | |
79 | ||
80 | The PCIe spec requires the Enhanced Configuration Access Method (ECAM) | |
81 | unless there's a standard firmware interface for config access, e.g., the | |
82 | ia64 SAL interface [7]. A host bridge consumes ECAM memory address space | |
83 | and converts memory accesses into PCI configuration accesses. The spec | |
84 | defines the ECAM address space layout and functionality; only the base of | |
85 | the address space is device-specific. An ACPI OS learns the base address | |
86 | from either the static MCFG table or a _CBA method in the PNP0A03 device. | |
87 | ||
88 | The MCFG table must describe the ECAM space of non-hot pluggable host | |
89 | bridges [8]. Since MCFG is a static table and can't be updated by hotplug, | |
90 | a _CBA method in the PNP0A03 device describes the ECAM space of a | |
91 | hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base | |
92 | address 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. |