€•›‡      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ!/translations/zh_CN/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ!/translations/zh_TW/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ!/translations/it_IT/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ!/translations/ja_JP/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ!/translations/ko_KR/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ!/translations/sp_SP/PCI/acpi-info”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒcomment”“”)”}”(hŒ SPDX-License-Identifier: GPL-2.0”h]”hŒ SPDX-License-Identifier: GPL-2.0”…””}”hh£sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1h¡hhhžhhŸŒ;/var/lib/git/docbuild/linux/Documentation/PCI/acpi-info.rst”h KubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒ(ACPI considerations for PCI host bridges”h]”hŒ(ACPI considerations for PCI host bridges”…””}”(hh»hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¹hh¶hžhhŸh³h KubhŒ	paragraph”“”)”}”(hŒThe general rule is that the ACPI namespace should describe everything the
OS might use unless there's another way for the OS to find it [1, 2].”h]”hŒ’The general rule is that the ACPI namespace should describe everything the
OS might use unless thereâ€™s another way for the OS to find it [1, 2].”…””}”(hhËhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Khh¶hžhubhÊ)”}”(hX?  For example, there's no standard hardware mechanism for enumerating PCI
host bridges, so the ACPI namespace must describe each host bridge, the
method for accessing PCI config space below it, the address space windows
the host bridge forwards to PCI (using _CRS), and the routing of legacy
INTx interrupts (using _PRT).”h]”hXA  For example, thereâ€™s no standard hardware mechanism for enumerating PCI
host bridges, so the ACPI namespace must describe each host bridge, the
method for accessing PCI config space below it, the address space windows
the host bridge forwards to PCI (using _CRS), and the routing of legacy
INTx interrupts (using _PRT).”…””}”(hhÙhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K
hh¶hžhubhÊ)”}”(hXç  PCI devices, which are below the host bridge, generally do not need to be
described via ACPI.  The OS can discover them via the standard PCI
enumeration mechanism, using config accesses to discover and identify
devices and read and size their BARs.  However, ACPI may describe PCI
devices if it provides power management or hotplug functionality for them
or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.”h]”hXç  PCI devices, which are below the host bridge, generally do not need to be
described via ACPI.  The OS can discover them via the standard PCI
enumeration mechanism, using config accesses to discover and identify
devices and read and size their BARs.  However, ACPI may describe PCI
devices if it provides power management or hotplug functionality for them
or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.”…””}”(hhçhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Khh¶hžhubhÊ)”}”(hXÚ  ACPI resource description is done via _CRS objects of devices in the ACPI
namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesn't have
a driver for the device [3].  That's important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.”h]”hXÞ  ACPI resource description is done via _CRS objects of devices in the ACPI
namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesnâ€™t have
a driver for the device [3].  Thatâ€™s important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.”…””}”(hhõhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Khh¶hžhubhÊ)”}”(hXŒ  Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
reserving address space.  The static tables are for things the OS needs to
know early in boot, before it can parse the ACPI namespace.  If a new table
is defined, an old OS needs to operate correctly even though it ignores the
table.  _CRS allows that because it is generic and understood by the old
OS; a static table does not.”h]”(hŒ/Static tables like MCFG, HPET, ECDT, etc., are ”…””}”(hj  hžhhŸNh NubhŒemphasis”“”)”}”(hŒ*not*”h]”hŒnot”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubhXX   mechanisms for
reserving address space.  The static tables are for things the OS needs to
know early in boot, before it can parse the ACPI namespace.  If a new table
is defined, an old OS needs to operate correctly even though it ignores the
table.  _CRS allows that because it is generic and understood by the old
OS; a static table does not.”…””}”(hj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K hh¶hžhubhÊ)”}”(hŒðIf the OS is expected to manage a non-discoverable device described via
ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
device's registers are.”h]”hŒòIf the OS is expected to manage a non-discoverable device described via
ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
deviceâ€™s registers are.”…””}”(hj%  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K'hh¶hžhubhÊ)”}”(hXÃ  PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
describe all the address space they consume.  This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
itself that are not forwarded to PCI.  The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
the device-specific details.  The host bridge registers also include ECAM
space, since it is consumed by the host bridge.”h]”hXÃ  PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
describe all the address space they consume.  This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
itself that are not forwarded to PCI.  The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
the device-specific details.  The host bridge registers also include ECAM
space, since it is consumed by the host bridge.”…””}”(hj3  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K,hh¶hžhubhÊ)”}”(hXÍ  ACPI defines a Consumer/Producer bit to distinguish the bridge registers
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
BIOSes didn't use that bit correctly.  The result is that the current ACPI
spec defines Consumer/Producer only for the Extended Address Space
descriptors; the bit should be ignored in the older QWord/DWord/Word
Address Space descriptors.  Consequently, OSes have to assume all
QWord/DWord/Word descriptors are windows.”h]”hX×  ACPI defines a Consumer/Producer bit to distinguish the bridge registers
(â€œConsumerâ€) from the bridge apertures (â€œProducerâ€) [4, 5], but early
BIOSes didnâ€™t use that bit correctly.  The result is that the current ACPI
spec defines Consumer/Producer only for the Extended Address Space
descriptors; the bit should be ignored in the older QWord/DWord/Word
Address Space descriptors.  Consequently, OSes have to assume all
QWord/DWord/Word descriptors are windows.”…””}”(hjA  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K7hh¶hžhubhÊ)”}”(hXÇ  Prior to the addition of Extended Address Space descriptors, the failure of
Consumer/Producer meant there was no way to describe bridge registers in
the PNP0A03/PNP0A08 device itself.  The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
know about it.”h]”hXÇ  Prior to the addition of Extended Address Space descriptors, the failure of
Consumer/Producer meant there was no way to describe bridge registers in
the PNP0A03/PNP0A08 device itself.  The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
know about it.”…””}”(hjO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K?hh¶hžhubhÊ)”}”(hX£  New architectures should be able to use "Consumer" Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
although a strict interpretation of [6] might prohibit this.  Old x86 and
ia64 kernels assume all address space descriptors, including "Consumer"
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.”h]”hX«  New architectures should be able to use â€œConsumerâ€ Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
although a strict interpretation of [6] might prohibit this.  Old x86 and
ia64 kernels assume all address space descriptors, including â€œConsumerâ€
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.”…””}”(hj]  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h KGhh¶hžhubhÊ)”}”(hX[  PNP0C02 "motherboard" devices are basically a catch-all.  There's no
programming model for them other than "don't use these resources for
anything else."  So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.”h]”hXg  PNP0C02 â€œmotherboardâ€ devices are basically a catch-all.  Thereâ€™s no
programming model for them other than â€œdonâ€™t use these resources for
anything else.â€  So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.”…””}”(hjk  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h KNhh¶hžhubhÊ)”}”(hX   The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
unless there's a standard firmware interface for config access, e.g., the
ia64 SAL interface [7].  A host bridge consumes ECAM memory address space
and converts memory accesses into PCI configuration accesses.  The spec
defines the ECAM address space layout and functionality; only the base of
the address space is device-specific.  An ACPI OS learns the base address
from either the static MCFG table or a _CBA method in the PNP0A03 device.”h]”hX  The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
unless thereâ€™s a standard firmware interface for config access, e.g., the
ia64 SAL interface [7].  A host bridge consumes ECAM memory address space
and converts memory accesses into PCI configuration accesses.  The spec
defines the ECAM address space layout and functionality; only the base of
the address space is device-specific.  An ACPI OS learns the base address
from either the static MCFG table or a _CBA method in the PNP0A03 device.”…””}”(hjy  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h KThh¶hžhubhÊ)”}”(hX›  The MCFG table must describe the ECAM space of non-hot pluggable host
bridges [8].  Since MCFG is a static table and can't be updated by hotplug,
a _CBA method in the PNP0A03 device describes the ECAM space of a
hot-pluggable host bridge [9].  Note that for both MCFG and _CBA, the base
address always corresponds to bus 0, even if the bus range below the bridge
(which is reported via _CRS) doesn't start at 0.”h]”hXŸ  The MCFG table must describe the ECAM space of non-hot pluggable host
bridges [8].  Since MCFG is a static table and canâ€™t be updated by hotplug,
a _CBA method in the PNP0A03 device describes the ECAM space of a
hot-pluggable host bridge [9].  Note that for both MCFG and _CBA, the base
address always corresponds to bus 0, even if the bus range below the bridge
(which is reported via _CRS) doesnâ€™t start at 0.”…””}”(hj‡  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K\hh¶hžhubhŒdefinition_list”“”)”}”(hhh]”(hŒdefinition_list_item”“”)”}”(hŒû[1] ACPI 6.2, sec 6.1:
For any device that is on a non-enumerable type of bus (for example, an
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
system firmware must supply an _HID object ... for each device to
enable OSPM to do that.
”h]”(hŒterm”“”)”}”(hŒ[1] ACPI 6.2, sec 6.1:”h]”hŒ[1] ACPI 6.2, sec 6.1:”…””}”(hj¢  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h Khhjœ  ubhŒ
definition”“”)”}”(hhh]”hÊ)”}”(hŒãFor any device that is on a non-enumerable type of bus (for example, an
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
system firmware must supply an _HID object ... for each device to
enable OSPM to do that.”h]”hŒåFor any device that is on a non-enumerable type of bus (for example, an
ISA bus), OSPM enumerates the devicesâ€™ identifier(s) and the ACPI
system firmware must supply an _HID object ... for each device to
enable OSPM to do that.”…””}”(hjµ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Kehj²  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjœ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h Khhj—  ubj›  )”}”(hX  [2] ACPI 6.2, sec 3.7:
The OS enumerates motherboard devices simply by reading through the
ACPI Namespace looking for devices with hardware IDs.

Each device enumerated by ACPI includes ACPI-defined objects in the
ACPI Namespace that report the hardware resources the device could
occupy [_PRS], an object that reports the resources that are currently
used by the device [_CRS], and objects for configuring those resources
[_SRS].  The information is used by the Plug and Play OS (OSPM) to
configure the devices.
”h]”(j¡  )”}”(hŒ[2] ACPI 6.2, sec 3.7:”h]”hŒ[2] ACPI 6.2, sec 3.7:”…””}”(hjÓ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h KshjÏ  ubj±  )”}”(hhh]”(hÊ)”}”(hŒyThe OS enumerates motherboard devices simply by reading through the
ACPI Namespace looking for devices with hardware IDs.”h]”hŒyThe OS enumerates motherboard devices simply by reading through the
ACPI Namespace looking for devices with hardware IDs.”…””}”(hjä  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Kkhjá  ubhÊ)”}”(hXn  Each device enumerated by ACPI includes ACPI-defined objects in the
ACPI Namespace that report the hardware resources the device could
occupy [_PRS], an object that reports the resources that are currently
used by the device [_CRS], and objects for configuring those resources
[_SRS].  The information is used by the Plug and Play OS (OSPM) to
configure the devices.”h]”hXn  Each device enumerated by ACPI includes ACPI-defined objects in the
ACPI Namespace that report the hardware resources the device could
occupy [_PRS], an object that reports the resources that are currently
used by the device [_CRS], and objects for configuring those resources
[_SRS].  The information is used by the Plug and Play OS (OSPM) to
configure the devices.”…””}”(hjò  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Knhjá  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjÏ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h Kshj—  hžhubj›  )”}”(hXÅ  [3] ACPI 6.2, sec 6.2:
OSPM uses device configuration objects to configure hardware resources
for devices enumerated via ACPI.  Device configuration objects provide
information about current and possible resource requirements, the
relationship between shared resources, and methods for configuring
hardware resources.

When OSPM enumerates a device, it calls _PRS to determine the resource
requirements of the device.  It may also call _CRS to find the current
resource settings for the device.  Using this information, the Plug and
Play system determines what resources the device should consume and
sets those resources by calling the deviceâ€™s _SRS control method.

In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
Unless otherwise specified, resources for a device are assumed to be
taken from the nearest matching resource above the device in the device
hierarchy.
”h]”(j¡  )”}”(hŒ[3] ACPI 6.2, sec 6.2:”h]”hŒ[3] ACPI 6.2, sec 6.2:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K†hj  ubj±  )”}”(hhh]”(hÊ)”}”(hX&  OSPM uses device configuration objects to configure hardware resources
for devices enumerated via ACPI.  Device configuration objects provide
information about current and possible resource requirements, the
relationship between shared resources, and methods for configuring
hardware resources.”h]”hX&  OSPM uses device configuration objects to configure hardware resources
for devices enumerated via ACPI.  Device configuration objects provide
information about current and possible resource requirements, the
relationship between shared resources, and methods for configuring
hardware resources.”…””}”(hj!  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Kvhj  ubhÊ)”}”(hX]  When OSPM enumerates a device, it calls _PRS to determine the resource
requirements of the device.  It may also call _CRS to find the current
resource settings for the device.  Using this information, the Plug and
Play system determines what resources the device should consume and
sets those resources by calling the deviceâ€™s _SRS control method.”h]”hX]  When OSPM enumerates a device, it calls _PRS to determine the resource
requirements of the device.  It may also call _CRS to find the current
resource settings for the device.  Using this information, the Plug and
Play system determines what resources the device should consume and
sets those resources by calling the deviceâ€™s _SRS control method.”…””}”(hj/  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K|hj  ubhÊ)”}”(hX&  In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
Unless otherwise specified, resources for a device are assumed to be
taken from the nearest matching resource above the device in the device
hierarchy.”h]”hX&  In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
Unless otherwise specified, resources for a device are assumed to be
taken from the nearest matching resource above the device in the device
hierarchy.”…””}”(hj=  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K‚hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j°  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K†hj—  hžhubj›  )”}”(hX>  [4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
  General Flags: Bit [0] Ignored

Extended Address Space Descriptor (.4)
  General Flags: Bit [0] Consumer/Producer:

    * 1 â€“ This device consumes this resource
    * 0 â€“ This device produces and consumes this resource
”h]”(j¡  )”}”(hŒ%[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:”h]”hŒ%[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:”…””}”(hj[  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h KhjW  ubj±  )”}”(hhh]”j–  )”}”(hhh]”(j›  )”}”(hŒVQWord/DWord/Word Address Space Descriptor (.1, .2, .3)
General Flags: Bit [0] Ignored
”h]”(j¡  )”}”(hŒ6QWord/DWord/Word Address Space Descriptor (.1, .2, .3)”h]”hŒ6QWord/DWord/Word Address Space Descriptor (.1, .2, .3)”…””}”(hjs  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h KŠhjo  ubj±  )”}”(hhh]”hÊ)”}”(hŒGeneral Flags: Bit [0] Ignored”h]”hŒGeneral Flags: Bit [0] Ignored”…””}”(hj„  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h KŠhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjo  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h KŠhjl  ubj›  )”}”(hŒ¹Extended Address Space Descriptor (.4)
General Flags: Bit [0] Consumer/Producer:

  * 1 â€“ This device consumes this resource
  * 0 â€“ This device produces and consumes this resource
”h]”(j¡  )”}”(hŒ&Extended Address Space Descriptor (.4)”h]”hŒ&Extended Address Space Descriptor (.4)”…””}”(hj¢  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h Khjž  ubj±  )”}”(hhh]”(hÊ)”}”(hŒ)General Flags: Bit [0] Consumer/Producer:”h]”hŒ)General Flags: Bit [0] Consumer/Producer:”…””}”(hj³  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Khj°  ubhŒblock_quote”“”)”}”(hŒc* 1 â€“ This device consumes this resource
* 0 â€“ This device produces and consumes this resource
”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒ(1 â€“ This device consumes this resource”h]”hÊ)”}”(hjÐ  h]”hŒ(1 â€“ This device consumes this resource”…””}”(hjÒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h KhjÎ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jÌ  hjÉ  ubjÍ  )”}”(hŒ60 â€“ This device produces and consumes this resource
”h]”hÊ)”}”(hŒ50 â€“ This device produces and consumes this resource”h]”hŒ50 â€“ This device produces and consumes this resource”…””}”(hjé  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Khjå  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jÌ  hjÉ  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ*”uh1jÇ  hŸh³h KhjÃ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jÁ  hŸh³h Khj°  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjž  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h Khjl  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j•  hji  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjW  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h Khj—  hžhubj›  )”}”(hŒè[5] ACPI 6.2, sec 19.6.43:
ResourceUsage specifies whether the Memory range is consumed by
this device (ResourceConsumer) or passed on to child devices
(ResourceProducer).  If nothing is specified, then
ResourceConsumer is assumed.
”h]”(j¡  )”}”(hŒ[5] ACPI 6.2, sec 19.6.43:”h]”hŒ[5] ACPI 6.2, sec 19.6.43:”…””}”(hj-  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K–hj)  ubj±  )”}”(hhh]”hÊ)”}”(hŒÌResourceUsage specifies whether the Memory range is consumed by
this device (ResourceConsumer) or passed on to child devices
(ResourceProducer).  If nothing is specified, then
ResourceConsumer is assumed.”h]”hŒÌResourceUsage specifies whether the Memory range is consumed by
this device (ResourceConsumer) or passed on to child devices
(ResourceProducer).  If nothing is specified, then
ResourceConsumer is assumed.”…””}”(hj>  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K“hj;  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hj)  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K–hj—  hžhubj›  )”}”(hX³  [6] PCI Firmware 3.2, sec 4.1.2:
If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware.  The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource.  For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI busâ€™s
_CRS.  The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
”h]”(j¡  )”}”(hŒ [6] PCI Firmware 3.2, sec 4.1.2:”h]”hŒ [6] PCI Firmware 3.2, sec 4.1.2:”…””}”(hj\  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K¢hjX  ubj±  )”}”(hhh]”hÊ)”}”(hX‘  If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware.  The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource.  For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI busâ€™s
_CRS.  The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.”h]”hX‘  If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware.  The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource.  For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under  _SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI busâ€™s
_CRS.  The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.”…””}”(hjm  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K™hjj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjX  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K¢hj—  hžhubj›  )”}”(hŒû[7] PCI Express 4.0, sec 7.2.2:
For systems that are PC-compatible, or that do not implement a
processor-architecture-specific firmware interface standard that allows
access to the Configuration Space, the ECAM is required as defined in
this section.
”h]”(j¡  )”}”(hŒ[7] PCI Express 4.0, sec 7.2.2:”h]”hŒ[7] PCI Express 4.0, sec 7.2.2:”…””}”(hj‹  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K¨hj‡  ubj±  )”}”(hhh]”hÊ)”}”(hŒÚFor systems that are PC-compatible, or that do not implement a
processor-architecture-specific firmware interface standard that allows
access to the Configuration Space, the ECAM is required as defined in
this section.”h]”hŒÚFor systems that are PC-compatible, or that do not implement a
processor-architecture-specific firmware interface standard that allows
access to the Configuration Space, the ECAM is required as defined in
this section.”…””}”(hjœ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K¥hj™  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j°  hj‡  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K¨hj—  hžhubj›  )”}”(hX®  [8] PCI Firmware 3.2, sec 4.1.2:
The MCFG table is an ACPI table that is used to communicate the base
addresses corresponding to the non-hot removable PCI Segment Groups
range within a PCI Segment Group available to the operating system at
boot. This is required for the PC-compatible systems.

The MCFG table is only used to communicate the base addresses
corresponding to the PCI Segment Groups available to the system at
boot.
”h]”(j¡  )”}”(hŒ [8] PCI Firmware 3.2, sec 4.1.2:”h]”hŒ [8] PCI Firmware 3.2, sec 4.1.2:”…””}”(hjº  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K²hj¶  ubj±  )”}”(hhh]”(hÊ)”}”(hX  The MCFG table is an ACPI table that is used to communicate the base
addresses corresponding to the non-hot removable PCI Segment Groups
range within a PCI Segment Group available to the operating system at
boot. This is required for the PC-compatible systems.”h]”hX  The MCFG table is an ACPI table that is used to communicate the base
addresses corresponding to the non-hot removable PCI Segment Groups
range within a PCI Segment Group available to the operating system at
boot. This is required for the PC-compatible systems.”…””}”(hjË  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K«hjÈ  ubhÊ)”}”(hŒ†The MCFG table is only used to communicate the base addresses
corresponding to the PCI Segment Groups available to the system at
boot.”h]”hŒ†The MCFG table is only used to communicate the base addresses
corresponding to the PCI Segment Groups available to the system at
boot.”…””}”(hjÙ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K°hjÈ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j°  hj¶  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K²hj—  hžhubj›  )”}”(hXù  [9] PCI Firmware 3.2, sec 4.1.3:
The _CBA (Memory mapped Configuration Base Address) control method is
an optional ACPI object that returns the 64-bit memory mapped
configuration base address for the hot plug capable host bridge. The
base address returned by _CBA is processor-relative address. The _CBA
control method evaluates to an Integer.

This control method appears under a host bridge object. When the _CBA
method appears under an active host bridge object, the operating system
evaluates this structure to identify the memory mapped configuration
base address corresponding to the PCI Segment Group for the bus number
range specified in _CRS method. An ACPI name space object that contains
the _CBA method must also contain a corresponding _SEG method.”h]”(j¡  )”}”(hŒ [9] PCI Firmware 3.2, sec 4.1.3:”h]”hŒ [9] PCI Firmware 3.2, sec 4.1.3:”…””}”(hj÷  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j   hŸh³h K¿hjó  ubj±  )”}”(hhh]”(hÊ)”}”(hX6  The _CBA (Memory mapped Configuration Base Address) control method is
an optional ACPI object that returns the 64-bit memory mapped
configuration base address for the hot plug capable host bridge. The
base address returned by _CBA is processor-relative address. The _CBA
control method evaluates to an Integer.”h]”hX6  The _CBA (Memory mapped Configuration Base Address) control method is
an optional ACPI object that returns the 64-bit memory mapped
configuration base address for the hot plug capable host bridge. The
base address returned by _CBA is processor-relative address. The _CBA
control method evaluates to an Integer.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h Kµhj  ubhÊ)”}”(hX   This control method appears under a host bridge object. When the _CBA
method appears under an active host bridge object, the operating system
evaluates this structure to identify the memory mapped configuration
base address corresponding to the PCI Segment Group for the bus number
range specified in _CRS method. An ACPI name space object that contains
the _CBA method must also contain a corresponding _SEG method.”h]”hX   This control method appears under a host bridge object. When the _CBA
method appears under an active host bridge object, the operating system
evaluates this structure to identify the memory mapped configuration
base address corresponding to the PCI Segment Group for the bus number
range specified in _CRS method. An ACPI name space object that contains
the _CBA method must also contain a corresponding _SEG method.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhŸh³h K»hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j°  hjó  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jš  hŸh³h K¿hj—  hžhubeh}”(h]”h ]”h"]”h$]”h&]”uh1j•  hh¶hžhhŸh³h Nubeh}”(h]”Œ(acpi-considerations-for-pci-host-bridges”ah ]”h"]”Œ(acpi considerations for pci host bridges”ah$]”h&]”uh1h´hhhžhhŸh³h Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”h³uh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(h¹NŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”ja  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”h³Œ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”j;  j8  sŒ	nametypes”}”j;  ‰sh}”j8  h¶sŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nhžhub.