tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
audk/OvmfPkg/Include/Guid/RootBridgesConnectedEventGr...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
999 B
C
Raw Normal View History

OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid QEMU's ACPI table generator can only create meaningful _CRS objects -- apertures -- for the root buses if all of the PCI devices behind those buses are actively decoding their IO and MMIO resources, at the time of the firmware fetching the "etc/table-loader" fw_cfg file. This is not a QEMU error; QEMU follows the definition of BARs (which are meaningless when decoding is disabled). Currently we hook up AcpiPlatformDxe to the PCI Bus driver's gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI Bus driver installs this protocol, it's *still* not the right time for fetching "etc/table-loader": although resources have been allocated and BARs have been programmed with them, the PCI Bus driver has also cleared IO and MMIO decoding in the command registers of the devices. Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to, because at that time the PCI Bus driver has not produced PciIo instances yet. Our Platform BDSes are responsible for connecting the root bridges, hence they know exactly when the PciIo instances become available -- not when PCI enumeration completes (signaled by the above protocol), but when the ConnectController() calls return. This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe. Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all devices, while it contacts QEMU for the ACPI payload. This patch introduces the event group GUID that we'll use for unleashing AcpiPlatformDxe from our Platform BDSes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-13 17:35:05 +01:00
/** @file
An event group GUID with which BDS indicates that PCI root bridges have been
connected, and PciIo protocol instances have become available.
Note that this differs from the PCI Enumeration Complete Protocol as defined
in the PI 1.1 specification. That protocol is installed by the PCI bus driver
after enumeration and resource allocation have been completed, but before
PciIo protocol instances are created.
Copyright (C) 2016, Red Hat, Inc.
OvmfPkg: Replace BSD License with BSD+Patent License https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 01:06:33 +02:00
SPDX-License-Identifier: BSD-2-Clause-Patent
OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid QEMU's ACPI table generator can only create meaningful _CRS objects -- apertures -- for the root buses if all of the PCI devices behind those buses are actively decoding their IO and MMIO resources, at the time of the firmware fetching the "etc/table-loader" fw_cfg file. This is not a QEMU error; QEMU follows the definition of BARs (which are meaningless when decoding is disabled). Currently we hook up AcpiPlatformDxe to the PCI Bus driver's gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI Bus driver installs this protocol, it's *still* not the right time for fetching "etc/table-loader": although resources have been allocated and BARs have been programmed with them, the PCI Bus driver has also cleared IO and MMIO decoding in the command registers of the devices. Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to, because at that time the PCI Bus driver has not produced PciIo instances yet. Our Platform BDSes are responsible for connecting the root bridges, hence they know exactly when the PciIo instances become available -- not when PCI enumeration completes (signaled by the above protocol), but when the ConnectController() calls return. This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe. Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all devices, while it contacts QEMU for the ACPI payload. This patch introduces the event group GUID that we'll use for unleashing AcpiPlatformDxe from our Platform BDSes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-13 17:35:05 +01:00
**/
#ifndef _ROOT_BRIDGES_CONNECTED_EVENT_GROUP_H_
#define _ROOT_BRIDGES_CONNECTED_EVENT_GROUP_H_
#define ROOT_BRIDGES_CONNECTED_EVENT_GROUP_GUID \
{ 0x24a2d66f, \
0xeedd, \
0x4086, \
{ 0x90, 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69 }, \
}
extern EFI_GUID gRootBridgesConnectedEventGroupGuid;
#endif