From: "Ard Biesheuvel" <ardb@kernel.org>
To: Pierre <Pierre.Gondois@arm.com>, Marc Zyngier <maz@kernel.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Sami Mujawar <sami.mujawar@arm.com>
Subject: Re: [PATCH v3 3/8] DynamicTablesPkg: AcpiSsdtPcieLibArm: Fix _PRT description
Date: Sat, 29 Jan 2022 16:52:02 +0100 [thread overview]
Message-ID: <CAMj1kXFmOZDuGf6R3jcTSQ9B0VDHFBcO8dNJkAfJ0_FuakUfJw@mail.gmail.com> (raw)
In-Reply-To: <20220128154103.20752-4-Pierre.Gondois@arm.com>
(+ Marc)
On Fri, 28 Jan 2022 at 16:41, <Pierre.Gondois@arm.com> wrote:
>
> From: Pierre Gondois <Pierre.Gondois@arm.com>
>
> In ACPI 6.4, s6.2.13, _PRT objects describing PCI legacy interrupts
> can be defined following 2 models.
> In the first model, a _SRS object must be described to modify the PCI
> interrupt. The _CRS and _PRS object allows to describe the PCI
> interrupt (level/edge triggered, active high/low).
> In the second model, the PCI interrupt cannot be described with a
> similar granularity. PCI interrupts are by default level triggered,
> active low.
>
> GicV2 SPI interrupts are level or edge triggered, active high. To
> correctly describe PCI interrupts, the first model is used, even though
> Arm Base Boot Requirements v1.0 requires to use the second mode.
>
There are two different issues here:
- using separate 'interrupt link' device objects with an Interrupt()
resource rather than a simple GSIV number
- whether _PRS and _SRS need to be implemented on those link objects.
The latter is simply not true - _PRS and _SRS are optional, and
pointless if there is only a single possible value, so there is really
no need to add them here.
As for the choice between the link object or the GSIV number: I don't
think INTx interrupts on ARM systems are actually level low, and the
GSIV option is widely used, also in platforms that exist in
edk2-platforms, without any reported issues.
I've cc'ed Marc, perhaps he can shed some light on this, but I'd
prefer to stick to the GSIV approach if we can, as it is much simpler.
> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
> ---
>
> Notes:
> v3:
> - New patch. [Pierre]
>
> .../AcpiSsdtPcieLibArm/SsdtPcieGenerator.c | 47 +++++++++++++++++--
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtPcieLibArm/SsdtPcieGenerator.c b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtPcieLibArm/SsdtPcieGenerator.c
> index 3e22587d4a25..6823a98795c8 100644
> --- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtPcieLibArm/SsdtPcieGenerator.c
> +++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtPcieLibArm/SsdtPcieGenerator.c
> @@ -1,7 +1,7 @@
> /** @file
> SSDT Pcie Table Generator.
>
> - Copyright (c) 2021, Arm Limited. All rights reserved.<BR>
> + Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.<BR>
>
> SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -295,6 +295,10 @@ GeneratePciDeviceInfo (
> Method (_CRS, 0) {
> Return CRS0
> })
> + Method (_PRS, 0) {
> + Return CRS0
> + })
> + Method (_SRS, 1) { }
> Method (_DIS) { }
> }
>
> @@ -302,9 +306,12 @@ GeneratePciDeviceInfo (
> PCI Firmware Specification - Revision 3.3,
> s3.5. "Device State at Firmware/Operating System Handoff"
>
> - The _PRS and _SRS are not supported, cf Arm Base Boot Requirements v1.0:
> + Warning: The Arm Base Boot Requirements v1.0 states the following:
> "The _PRS (Possible Resource Settings) and _SRS (Set Resource Settings)
> are not supported."
> + However, the first model to describe PCI legacy interrupts is used (cf. ACPI
> + 6.4 s6.2.13) as PCI defaults (Level Triggered, Active Low) are not compatible
> + with GICv2 (must be Active High).
>
> @param [in] Irq Interrupt controller interrupt.
> @param [in] IrqFlags Interrupt flags.
> @@ -416,7 +423,41 @@ GenerateLinkDevice (
> return Status;
> }
>
> - // ASL:Method (_DIS, 1) {}
> + // ASL:
> + // Method (_PRS, 0) {
> + // Return (CRS0)
> + // }
> + Status = AmlCodeGenMethodRetNameString (
> + "_PRS",
> + "CRS0",
> + 0,
> + FALSE,
> + 0,
> + LinkNode,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + ASSERT (0);
> + return Status;
> + }
> +
> + // ASL:Method (_SRS, 1) {}
> + // Not possible to disable interrupts.
> + Status = AmlCodeGenMethodRetNameString (
> + "_SRS",
> + NULL,
> + 1,
> + FALSE,
> + 0,
> + LinkNode,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + ASSERT (0);
> + return Status;
> + }
> +
> + // ASL:Method (_DIS, 0) {}
> // Not possible to disable interrupts.
> Status = AmlCodeGenMethodRetNameString (
> "_DIS",
> --
> 2.25.1
>
next prev parent reply other threads:[~2022-01-29 15:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 15:40 [PATCH v3 0/8] Add ACPI support for Kvmtool PierreGondois
2022-01-28 15:40 ` [PATCH v3 1/8] DynamicTablesPkg: Print specifier macro for CM_OBJECT_ID PierreGondois
2022-01-28 15:40 ` [PATCH v3 2/8] DynamicTablesPkg: FdtHwInfoParserLib: Parse Pmu info PierreGondois
2022-01-29 15:33 ` [edk2-devel] " Ard Biesheuvel
2022-01-28 15:40 ` [PATCH v3 3/8] DynamicTablesPkg: AcpiSsdtPcieLibArm: Fix _PRT description PierreGondois
2022-01-29 15:52 ` Ard Biesheuvel [this message]
2022-01-29 18:20 ` Marc Zyngier
2022-01-31 12:59 ` PierreGondois
2022-01-31 13:52 ` Marc Zyngier
2022-01-31 14:54 ` Ard Biesheuvel
2022-01-28 15:40 ` [PATCH v3 4/8] ArmVirtPkg: Add cspell exceptions PierreGondois
2022-01-28 15:41 ` [PATCH v3 5/8] ArmVirtPkg/Kvmtool: Add DSDT ACPI table PierreGondois
2022-01-31 15:17 ` [edk2-devel] " Rebecca Cran
2022-01-31 15:21 ` Sami Mujawar
2022-02-01 16:55 ` PierreGondois
2022-02-01 16:56 ` Ard Biesheuvel
2022-02-01 16:56 ` Ard Biesheuvel
2022-02-01 16:56 ` Ard Biesheuvel
2022-02-01 17:02 ` PierreGondois
2022-02-01 17:04 ` Ard Biesheuvel
2022-02-01 17:07 ` PierreGondois
2022-01-28 15:41 ` [PATCH v3 6/8] ArmVirtPkg/Kvmtool: Add Configuration Manager PierreGondois
2022-01-28 15:41 ` [PATCH v3 7/8] ArmVirtPkg/Kvmtool: Enable ACPI support PierreGondois
2022-01-28 15:41 ` [PATCH v3 8/8] ArmVirtPkg/Kvmtool: Enable Acpiview PierreGondois
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXFmOZDuGf6R3jcTSQ9B0VDHFBcO8dNJkAfJ0_FuakUfJw@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox