0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 ========================================
0004 ACPI considerations for PCI host bridges
0005 ========================================
0006
0007 The general rule is that the ACPI namespace should describe everything the
0008 OS might use unless there's another way for the OS to find it [1, 2].
0009
0010 For example, there's no standard hardware mechanism for enumerating PCI
0011 host bridges, so the ACPI namespace must describe each host bridge, the
0012 method for accessing PCI config space below it, the address space windows
0013 the host bridge forwards to PCI (using _CRS), and the routing of legacy
0014 INTx interrupts (using _PRT).
0015
0016 PCI devices, which are below the host bridge, generally do not need to be
0017 described via ACPI. The OS can discover them via the standard PCI
0018 enumeration mechanism, using config accesses to discover and identify
0019 devices and read and size their BARs. However, ACPI may describe PCI
0020 devices if it provides power management or hotplug functionality for them
0021 or if the device has INTx interrupts connected by platform interrupt
0022 controllers and a _PRT is needed to describe those connections.
0023
0024 ACPI resource description is done via _CRS objects of devices in the ACPI
0025 namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
0026 _CRS and figure out what resource is being consumed even if it doesn't have
0027 a driver for the device [3]. That's important because it means an old OS
0028 can work correctly even on a system with new devices unknown to the OS.
0029 The new devices might not do anything, but the OS can at least make sure no
0030 resources conflict with them.
0031
0032 Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
0033 reserving address space. The static tables are for things the OS needs to
0034 know early in boot, before it can parse the ACPI namespace. If a new table
0035 is defined, an old OS needs to operate correctly even though it ignores the
0036 table. _CRS allows that because it is generic and understood by the old
0037 OS; a static table does not.
0038
0039 If the OS is expected to manage a non-discoverable device described via
0040 ACPI, that device will have a specific _HID/_CID that tells the OS what
0041 driver to bind to it, and the _CRS tells the OS and the driver where the
0042 device's registers are.
0043
0044 PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
0045 describe all the address space they consume. This includes all the windows
0046 they forward down to the PCI bus, as well as registers of the host bridge
0047 itself that are not forwarded to PCI. The host bridge registers include
0048 things like secondary/subordinate bus registers that determine the bus
0049 range below the bridge, window registers that describe the apertures, etc.
0050 These are all device-specific, non-architected things, so the only way a
0051 PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
0052 the device-specific details. The host bridge registers also include ECAM
0053 space, since it is consumed by the host bridge.
0054
0055 ACPI defines a Consumer/Producer bit to distinguish the bridge registers
0056 ("Consumer") from the bridge apertures ("Producer") [4, 5], but early
0057 BIOSes didn't use that bit correctly. The result is that the current ACPI
0058 spec defines Consumer/Producer only for the Extended Address Space
0059 descriptors; the bit should be ignored in the older QWord/DWord/Word
0060 Address Space descriptors. Consequently, OSes have to assume all
0061 QWord/DWord/Word descriptors are windows.
0062
0063 Prior to the addition of Extended Address Space descriptors, the failure of
0064 Consumer/Producer meant there was no way to describe bridge registers in
0065 the PNP0A03/PNP0A08 device itself. The workaround was to describe the
0066 bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
0067 With the exception of ECAM, the bridge register space is device-specific
0068 anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
0069 know about it.
0070
0071 New architectures should be able to use "Consumer" Extended Address Space
0072 descriptors in the PNP0A03 device for bridge registers, including ECAM,
0073 although a strict interpretation of [6] might prohibit this. Old x86 and
0074 ia64 kernels assume all address space descriptors, including "Consumer"
0075 Extended Address Space ones, are windows, so it would not be safe to
0076 describe bridge registers this way on those architectures.
0077
0078 PNP0C02 "motherboard" devices are basically a catch-all. There's no
0079 programming model for them other than "don't use these resources for
0080 anything else." So a PNP0C02 _CRS should claim any address space that is
0081 (1) not claimed by _CRS under any other device object in the ACPI namespace
0082 and (2) should not be assigned by the OS to something else.
0083
0084 The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
0085 unless there's a standard firmware interface for config access, e.g., the
0086 ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
0087 and converts memory accesses into PCI configuration accesses. The spec
0088 defines the ECAM address space layout and functionality; only the base of
0089 the address space is device-specific. An ACPI OS learns the base address
0090 from either the static MCFG table or a _CBA method in the PNP0A03 device.
0091
0092 The MCFG table must describe the ECAM space of non-hot pluggable host
0093 bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
0094 a _CBA method in the PNP0A03 device describes the ECAM space of a
0095 hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
0096 address always corresponds to bus 0, even if the bus range below the bridge
0097 (which is reported via _CRS) doesn't start at 0.
0098
0099
0100 [1] ACPI 6.2, sec 6.1:
0101 For any device that is on a non-enumerable type of bus (for example, an
0102 ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
0103 system firmware must supply an _HID object ... for each device to
0104 enable OSPM to do that.
0105
0106 [2] ACPI 6.2, sec 3.7:
0107 The OS enumerates motherboard devices simply by reading through the
0108 ACPI Namespace looking for devices with hardware IDs.
0109
0110 Each device enumerated by ACPI includes ACPI-defined objects in the
0111 ACPI Namespace that report the hardware resources the device could
0112 occupy [_PRS], an object that reports the resources that are currently
0113 used by the device [_CRS], and objects for configuring those resources
0114 [_SRS]. The information is used by the Plug and Play OS (OSPM) to
0115 configure the devices.
0116
0117 [3] ACPI 6.2, sec 6.2:
0118 OSPM uses device configuration objects to configure hardware resources
0119 for devices enumerated via ACPI. Device configuration objects provide
0120 information about current and possible resource requirements, the
0121 relationship between shared resources, and methods for configuring
0122 hardware resources.
0123
0124 When OSPM enumerates a device, it calls _PRS to determine the resource
0125 requirements of the device. It may also call _CRS to find the current
0126 resource settings for the device. Using this information, the Plug and
0127 Play system determines what resources the device should consume and
0128 sets those resources by calling the device’s _SRS control method.
0129
0130 In ACPI, devices can consume resources (for example, legacy keyboards),
0131 provide resources (for example, a proprietary PCI bridge), or do both.
0132 Unless otherwise specified, resources for a device are assumed to be
0133 taken from the nearest matching resource above the device in the device
0134 hierarchy.
0135
0136 [4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
0137 QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
0138 General Flags: Bit [0] Ignored
0139
0140 Extended Address Space Descriptor (.4)
0141 General Flags: Bit [0] Consumer/Producer:
0142
0143 * 1 – This device consumes this resource
0144 * 0 – This device produces and consumes this resource
0145
0146 [5] ACPI 6.2, sec 19.6.43:
0147 ResourceUsage specifies whether the Memory range is consumed by
0148 this device (ResourceConsumer) or passed on to child devices
0149 (ResourceProducer). If nothing is specified, then
0150 ResourceConsumer is assumed.
0151
0152 [6] PCI Firmware 3.2, sec 4.1.2:
0153 If the operating system does not natively comprehend reserving the
0154 MMCFG region, the MMCFG region must be reserved by firmware. The
0155 address range reported in the MCFG table or by _CBA method (see Section
0156 4.1.3) must be reserved by declaring a motherboard resource. For most
0157 systems, the motherboard resource would appear at the root of the ACPI
0158 namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
0159 the resources in this case should not be claimed in the root PCI bus’s
0160 _CRS. The resources can optionally be returned in Int15 E820 or
0161 EFIGetMemoryMap as reserved memory but must always be reported through
0162 ACPI as a motherboard resource.
0163
0164 [7] PCI Express 4.0, sec 7.2.2:
0165 For systems that are PC-compatible, or that do not implement a
0166 processor-architecture-specific firmware interface standard that allows
0167 access to the Configuration Space, the ECAM is required as defined in
0168 this section.
0169
0170 [8] PCI Firmware 3.2, sec 4.1.2:
0171 The MCFG table is an ACPI table that is used to communicate the base
0172 addresses corresponding to the non-hot removable PCI Segment Groups
0173 range within a PCI Segment Group available to the operating system at
0174 boot. This is required for the PC-compatible systems.
0175
0176 The MCFG table is only used to communicate the base addresses
0177 corresponding to the PCI Segment Groups available to the system at
0178 boot.
0179
0180 [9] PCI Firmware 3.2, sec 4.1.3:
0181 The _CBA (Memory mapped Configuration Base Address) control method is
0182 an optional ACPI object that returns the 64-bit memory mapped
0183 configuration base address for the hot plug capable host bridge. The
0184 base address returned by _CBA is processor-relative address. The _CBA
0185 control method evaluates to an Integer.
0186
0187 This control method appears under a host bridge object. When the _CBA
0188 method appears under an active host bridge object, the operating system
0189 evaluates this structure to identify the memory mapped configuration
0190 base address corresponding to the PCI Segment Group for the bus number
0191 range specified in _CRS method. An ACPI name space object that contains
0192 the _CBA method must also contain a corresponding _SEG method.
