The ACPI specification v6.5, sTable 5.158: Processor Structure Flags
states that:
"""
The processor container will have a matching ID
value returned through the _UID method. As not every pro-
cessor hierarchy node structure in PPTT may have a matching
processor container, this flag indicates whether the ACPI pro-
cessor ID points to valid entry. Where a valid entry is possible
the ACPI Processor ID and _UID method are mandatory.
"""
And in:
Table 5.157: Processor Hierarchy Node Structure
"""
If the processor structure rep-
resents a group of associated processors, the structure might
match a processor container in the name space. In that case
this entry will match the value of the _UID method of the as-
sociated processor container. Where there is a match it must
be represented. The flags field, described in Processor Struc-
ture Flags, includes a bit to describe whether the ACPI pro-
cessor ID is valid.
"""
The DynamicTablesPkg currently creates a processor container:
- in the SSDT CPU Topology generator, with the _HID=ACPI0010,
and with a valid _UID
- in the PPTT table
for each CM_ARCH_COMMON_PROC_HIERARCHY_INFO structure.
Thus:
- all the processor containers should have the VALID bit set
if the SSDT CPU Topology table is present.
- if the SSDT CPU Topology table is present, but there is no
PPTT table, then the state of the VALID bit is ignored.
A contrario, an example where the VALID bit should not be set
would be if:
- the SSDT CPU Topology generator is absent
- no processor container is created in the SSDT topology,
i.e. if a flat hierarchy is created.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The processor containers might have an associated _UID:
- in their SSDT topology representation
- in their PPTT representation, in the "ACPI Processor ID" field
The _UID of the processor containers is independently generated
by the PPTT and SSDT CPU topology generators. Make use of the newly
created MetadataObjLib to generate a unique and common per-processor
container _UID values.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Introduce support for generating ACPI CPU SSDT table
for the X64 architecture.
Creates processor objects based on configuration data.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
The GICC is an ARM specific structure. Other architectures have different
local interrupt controller structures from which CPU topology can be
created. Avoid the GICC reference in common code by:
- creating a wrapper CreateTopologyFromIntC() instead of
CreateTopologyFromGicC() so that different archs can implement
it differently.
- implementing arch specific functions to get the AcpiProcessorUid,
CpcToken, EtToken and use them instead of using the GicC CM object
directly.
Suggested-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Allow other architectures to reuse ACPI common libraries by:
- Removing the Arm prefix from the BASE_NAME
- Moving Arm specific libraries/packages to ARM/AARCH64
specific sections in the .inf files
Also remove the empty .inf sections.
Suggested-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Some of the ACPI table generators are generic enough to be re-used
by other architectures. Move the following generators to a
'Common' folder:
- AcpiDbg2Lib
- AcpiFadtLib
- AcpiMcfgLib
- AcpiPcctLib
- AcpiPpttLib
- AcpiRawLib
- AcpiSpcrLib
- AcpiSratLib
- SsdtSerialPortLib
- SsdtCpuTopologyLib
- SsdtPcieLib
and update DynamicTables.dsc.inc accordingly.
Suggested-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
