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>
This commit is contained in:
Laszlo Ersek 2017-03-17 13:47:35 +01:00
parent 6244c8924e
commit 05db0948cc
2 changed files with 38 additions and 0 deletions

View File

@ -56,6 +56,9 @@
gFdtHobGuid = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 0xAD, 0x3F, 0x71, 0x6D } } gFdtHobGuid = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 0xAD, 0x3F, 0x71, 0x6D } }
gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } } gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }
## Include/Guid/PlatformHasAcpi.h
gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
[Protocols.common] [Protocols.common]
gHardwareInterruptProtocolGuid = { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } } gHardwareInterruptProtocolGuid = { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }
gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } } gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }

View File

@ -0,0 +1,35 @@
/** @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