On Tue, Oct 19, 2021 at 01:14 AM, PierreGondois wrote:
Hi Khasim,

2 minor comments:

On 10/10/21 19:29, Khasim Mohammed via groups.io wrote:
This patch creates Dsdt.asl, SsdtPci.asl and SsdtRemotePci.asl files
to provide the platform specific APCI table entries.

Three PCI root ports are available on N1Sdp, PCI0 is the default root port
PCI1 is the CCIX root port and PCI2 is the Remote host root port.

The Remote host specific entries are defined in a separate file
SsdtRemotePci.asl to avoid confusions with other PCI entries
and for better readability and understanding of interfaces.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Khasim Syed Mohammed <khasim.mohammed@arm.com>
Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
Signed-off-by: anukou01 <anurag.koul@arm.com>
Signed-off-by: Manoj Kumar <manoj.kumar3@arm.com>
---
.../AslTables/Dsdt.asl | 477 ++++++++++++++++++
.../AslTables/SsdtPci.asl | 247 +++++++++
.../AslTables/SsdtRemotePci.asl | 156 ++++++
3 files changed, 880 insertions(+)
create mode 100644 Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/Dsdt.asl
create mode 100644 Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtPci.asl
create mode 100644 Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtRemotePci.asl

diff --git a/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/Dsdt.asl b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/Dsdt.asl
new file mode 100644
index 0000000000..0d7dde1a73
--- /dev/null
+++ b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/Dsdt.asl
@@ -0,0 +1,477 @@
+/** @file
+ Differentiated System Description Table Fields (DSDT)
+
+ Copyright (c) 2021, ARM Limited. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
Is it possible to add a '@par Reference(s):' section in the header
(e.g.:
edk2/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c)

I believe you used these documents:

-ACPI for CoreSight 1.1, Platform Design Document
-ACPI for Arm Components  1.0, Platform Design Document

+
+#include "N1SdpAcpiHeader.h"
+#include "NeoverseN1Soc.h"
+
+#define ACPI_GRAPH_REV 0
+#define ACPI_GRAPH_UUID "ab02a46b-74c7-45a2-bd68-f7d344ef2153"
+
+#define CORESIGHT_GRAPH_UUID "3ecbc8b6-1d0e-4fb3-8107-e627f805c6cd"
+
+#define CS_LINK_MASTER 1
+#define CS_LINK_SLAVE 0
+
[snip]
diff --git a/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtPci.asl b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtPci.asl
new file mode 100644
index 0000000000..87a4fdaf88
--- /dev/null
+++ b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtPci.asl
@@ -0,0 +1,247 @@
+/** @file
+ Secondary System Description Table (SSDT)
+
+ Copyright (c) 2021, ARM Limited. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "N1SdpAcpiHeader.h"
+
+/*
+ See ACPI 6.4 Section 6.2.13
+
+ There are two ways that _PRT can be used.
+
+ In the first model, a PCI Link device is used to provide additional
+ configuration information such as whether the interrupt is Level or
+ Edge triggered, it is active High or Low, Shared or Exclusive, etc.
+
+ In the second model, the PCI interrupts are hardwired to specific
+ interrupt inputs on the interrupt controller and are not
+ configurable. In this case, the Source field in _PRT does not
+ reference a device, but instead contains the value zero, and the
+ Source Index field contains the global system interrupt to which the
+ PCI interrupt is hardwired.
+
+ We use the first model with link indirection to set the correct
+ interrupt type as PCI defaults (Level Triggered, Active Low) are not
+ compatible with GICv2.
+*/
+#define LNK_DEVICE(Unique_Id, Link_Name, irq) \
+ Device(Link_Name) { \
+ Name(_HID, EISAID("PNP0C0F")) \
+ Name(_UID, Unique_Id) \
+ Name(_PRS, ResourceTemplate() { \
+ Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive) { irq } \
+ }) \
+ Method (_CRS, 0) { Return (_PRS) } \
+ Method (_SRS, 1) { } \
+ Method (_DIS) { } \
+}
+
+#define PRT_ENTRY(Address, Pin, Link) \
+ Package (4) { \
+ Address, /* uses the same format as _ADR */ \
+ Pin, /* The PCI pin number of the device (0-INTA, 1-INTB, 2-INTC, 3-INTD) */ \
+ Link, /* Interrupt allocated via Link device */ \
+ Zero /* global system interrupt number (no used) */ \
+}
+
+/*
+ See Reference [1] 6.1.1
+ "High word-Device #, Low word-Function #. (for example, device 3,
+ function 2 is 0x00030002). To refer to all the functions on a device #,
+ use a function number of FFFF)."
+*/
+#define ROOT_PRT_ENTRY(Pin, Link) PRT_ENTRY(0x0000FFFF, Pin, Link) // Device 0 for Bridge.
+
+DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "N1Sdp",
+ EFI_ACPI_ARM_OEM_REVISION)
+{
+ Scope (_SB) {
+
+ // PCI Root Complex
+ LNK_DEVICE(1, LNKA, 201)
+ LNK_DEVICE(2, LNKB, 202)
+ LNK_DEVICE(3, LNKC, 203)
+ LNK_DEVICE(4, LNKD, 204)
+ LNK_DEVICE(5, LNKE, 233)
+ LNK_DEVICE(6, LNKF, 234)
+ LNK_DEVICE(7, LNKG, 235)
+ LNK_DEVICE(8, LNKH, 236)
+
+ // PCI Root Complex
+ Device(PCI0) {
+ Name (_HID, EISAID("PNP0A08")) // PCI Express Root Bridge
+ Name (_CID, EISAID("PNP0A03")) // Compatible PCI Root Bridge
+ Name (_SEG, Zero) // PCI Segment Group number
+ Name (_BBN, Zero) // PCI Base Bus Number
+ Name (_CCA, 1) // Cache Coherency Attribute
+
+ // Root Complex 0
+ Device (RP0) {
+ Name(_ADR, 0xF0000000) // Dev 0, Func 0
+ }
Isn't it necessary to have an _OSC object as in
edk2-platforms/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/AslTables/SsdtPci.asl
?

Same question for SsdtRemotePci.asl

[snip]
Hi Pierre,

Yes, the _OSC object should have been implemented but unfortunately there are few PCIe Quirks and we are managing with additional patches to kernel. I am not sure if any of the _OSC functionality would result in exporting undesirable functionality due to these hardware errors. 

I have a made a note of this suggestion, we will experiment the _OSC object and functionality and if everything works as expected then I will submit a follow on patch later. 

Thanks.

Regards,
Khasim



Regards,

Pierre