[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251218-gicv5-host-acpi-v2-0-eec76cd1d40b@kernel.org>
Date: Thu, 18 Dec 2025 11:14:26 +0100
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
Robert Moore <robert.moore@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
Hanjun Guo <guohanjun@...wei.com>, Sudeep Holla <sudeep.holla@....com>,
Marc Zyngier <maz@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>
Cc: linux-acpi@...r.kernel.org, acpica-devel@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-pci@...r.kernel.org, Lorenzo Pieralisi <lpieralisi@...nel.org>,
Jose Marinho <jose.marinho@....com>
Subject: [PATCH v2 0/7] irqchip/gic-v5: Code first ACPI boot support
The ACPI and ACPI IORT specifications were updated to support bindings
required to describe GICv5 based systems.
The ACPI specification GICv5 bindings ECR [1] were approved and the
required changes merged in the ACPICA upstream repository[5].
The Arm IORT specification [2] has been updated to include GICv5 IWB
specific bindings in revision E.g.
Implement kernel code that - based on the aforementioned bindings - adds
support for GICv5 ACPI probing.
ACPICA changes supporting the bindings are posted with the series; they
were cherry-picked from the upcoming ACPICA Linuxised release patches
and they should _not_ be merged in any upstream branch because the
full set of Linuxised ACPICA changes will be subsequently posted in
order to be merged, I added the two ACPICA patches to make the series
self-contained.
The ACPI bindings were prototyped in edk2 - code available in these
branches [3][4].
===========================
Kernel implementation notes
===========================
IRS and ITS probing is triggered using the standard irqchip ACPI probing
mechanism - there is no significant difference compared to previous GIC
versions other.
The only difference that is worth noting is that GICv3/4 systems include a
single MADT component describing the interrupt controller (ie GIC distributor)
whereas GICv5 systems include one or more IRSes. The probing code is
implemented so that an MADT IRS detection triggers probing for all IRSes
in one go.
The IWB driver probes like any other ACPI device. IORT code is updated so
that a deviceID for the IWB can be detected.
The only major change compared to GICv3/4 systems is the GSI namespace that
is split between PPI/SPI IRQs and IWB backed IRQs.
The main GSI handle - to map an IRQ - has to detect whether to look-up
using the top level GSI domain or an IWB domain in that the two IRQ
namespaces are decoupled.
IORT code implements the logic to retrieve an IWB domain by looking up its
IWB frame id, as described in [1].
Most important implementation detail worth noting is that - at this stage -
ACPI code is not capable of handling devices probe order IRQ dependency on
the interrupt controller driver their IRQ is routed to.
This is not an issue on GICv3/4 systems in that the full GIC hierarchy
probes earlier than any other device, so by the time IRQs mappings have to
be carried out (ie acpi_register_gsi()) the GIC drivers have already
probed.
On GICv5 systems, the IWB is modelled as a device and its device driver
probes at device_initcall time. That's when the IWB IRQ domain is actually
registered - which poses problems for devices whose IRQs are IWB routed and
require to resolve the IRQ mapping before the IWB driver has a chance to
probe.
Work on resolving devices<->IWB probe order dependency has started in
parallel with this series and will be posted shortly.
For PPI/SPI/LPI backed IRQs the probe dependency is not a problem because
in GICv5 systems the IRSes and ITSes probe early so their IRQ domain are
set in place before devices require IRQ mappings.
ACPICA patches are a Linuxised version of ACPICA GICv5 upstream changes
[5] and should not be considered for merging because they would conflict
with the full ACPICA release changes patchset that will be posted later
in this dev cycle (owing to patch dependencies in the ACPICA commit
history) they are there so that the patch series is self-contained.
[1] https://github.com/tianocore/edk2/issues/11148
[2] https://developer.arm.com/documentation/den0049/eg
[3] https://github.com/LeviYeoReum/edk2/tree/levi/gicv5_patch
[4] https://github.com/LeviYeoReum/edk2-platforms/tree/levi/gicv5_patch
[5] https://github.com/acpica/acpica/commits/master/
Signed-off-by: Lorenzo Pieralisi <lpieralisi@...nel.org>
---
Changes in v2:
- Cherry-picked ACPICA upstream changes
- Minor editorial changes
- Removed the "not for merging" tag because now ACPI specs are approved
- Rebased against v6.19-rc1
- Link to v1: https://lore.kernel.org/r/20251028-gicv5-host-acpi-v1-0-01a862feb5ca@kernel.org
---
Jose Marinho (2):
ACPICA: Add GICv5 MADT structures
ACPICA: Add Arm IORT IWB node definitions
Lorenzo Pieralisi (5):
irqdomain: Add parent field to struct irqchip_fwid
PCI/MSI: Make the pci_msi_map_rid_ctlr_node() interface firmware agnostic
irqchip/gic-v5: Add ACPI IRS probing
irqchip/gic-v5: Add ACPI ITS probing
irqchip/gic-v5: Add ACPI IWB probing
drivers/acpi/arm64/iort.c | 190 +++++++++++++++++++-----
drivers/acpi/bus.c | 3 +
drivers/irqchip/irq-gic-its-msi-parent.c | 43 +++---
drivers/irqchip/irq-gic-v5-irs.c | 246 ++++++++++++++++++++++++-------
drivers/irqchip/irq-gic-v5-its.c | 132 ++++++++++++++++-
drivers/irqchip/irq-gic-v5-iwb.c | 42 ++++--
drivers/irqchip/irq-gic-v5.c | 138 ++++++++++++++---
drivers/pci/msi/irqdomain.c | 24 ++-
include/acpi/actbl2.h | 56 ++++++-
include/linux/acpi.h | 1 +
include/linux/acpi_iort.h | 11 +-
include/linux/irqchip/arm-gic-v5.h | 8 +
include/linux/irqdomain.h | 30 +++-
include/linux/msi.h | 3 +-
kernel/irq/irqdomain.c | 14 +-
15 files changed, 784 insertions(+), 157 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251022-gicv5-host-acpi-d59d6c1d3d07
Best regards,
--
Lorenzo Pieralisi <lpieralisi@...nel.org>
Powered by blists - more mailing lists