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

36 lines
1.3 KiB
C
Raw Normal View History

EmbeddedPkg: introduce EDKII Platform Has ACPI GUID The presence of this GUID in the PPI database, and/or in the DXE protocol database (as dictated by the platform's needs in these firmware phases) implies that the platform provides the operating system with an ACPI-based hardware description. This is not necessarily exclusive with other types of hardware description (for example, a Device Tree-based one). A platform PEIM and/or DXE driver is supposed to produce a single instance of the PPI and/or protocol (with NULL contents), if appropriate. The decision to produce the PPI and/or protocol is platform specific; for example, in the DXE phase, it could depend on an HII checkbox / underlying non-volatile UEFI variable. In the DXE phase, the protocol is meant to be depended-upon by "MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly: * In the long term, interested platforms will establish this dependency by hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to the GUID introduced here. (For the prerequisite BaseTools feature, refer to <https://bugzilla.tianocore.org/show_bug.cgi?id=443>). * In the short term, an interested platform may hook a private NULL-class library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe. Such a library instance would be a specialization of the above described generic DepexLib, with the DEPEX open-coded on the GUID introduced here. Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to produce or not to produce a NULL protocol instance with this GUID. In turn, other (platform and universal) DXE drivers that produce ACPI tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late enough" callback (such as Ready To Boot). Because this GUID is not standard, it is prefixed with EDKII / Edkii, as seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is made to avoid the phrase "AcpiPlatform", as that belongs to drivers / libraries that produce platform specific ACPI content (as opposed to deciding whether the entire firmware will have access to EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 13:47:35 +01:00
/** @file
EDKII Platform Has ACPI GUID
A NULL protocol instance with this GUID in the DXE protocol database, and/or
a NULL PPI with this GUID in the PPI database, implies that the platform
provides the operating system with an ACPI-based hardware description. Note
that this is not necessarily exclusive with different kinds of hardware
description (for example, a Device Tree-based one). A platform driver and/or
PEIM is supposed to produce a single instance of the protocol and/or PPI
(with NULL contents), if appropriate.
Copyright (C) 2017, Red Hat, Inc.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License that accompanies this
distribution. The full text of the license may be found at
http://opensource.org/licenses/bsd-license.php.
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
**/
#ifndef __EDKII_PLATFORM_HAS_ACPI_H__
#define __EDKII_PLATFORM_HAS_ACPI_H__
#define EDKII_PLATFORM_HAS_ACPI_GUID \
{ \
0xf0966b41, 0xc23f, 0x41b9, \
{ 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } \
}
extern EFI_GUID gEdkiiPlatformHasAcpiGuid;
#endif