[v3,0/7] irqchip/apple-aic: Add support for AICv2

Message

Hector Martin March 9, 2022, 7:21 p.m. UTC

Hi folks,

In the t6000/t6001 (M1 Pro / Max) SoCs, Apple introduced a new version
of their interrupt controller. This is a significant departure from
AICv1 and seems designed to better scale to larger chips. This series
adds support for it to the existing AIC driver.

Gone are CPU affinities; instead there seems to be some kind of
"automagic" dispatch to willing CPU cores, and cores can also opt-out
via an IMP-DEF sysreg (!). Right now the bootloader just sets up all
cores to accept IRQs, and we ignore all this and let the magic
algorithm pick a CPU to accept the IRQ. In the future, we might start
making use of these finer-grained capabilities for e.g. better
real-time guarantees (CPUs running RT threads might opt out of IRQs).

Legacy IPI support is also gone, so this implements Fast IPI support.
Fast IPIs are implemented entirely in the CPU core complexes, using
FIQs and IMP-DEF sysregs. This is also supported on t8103/M1, so we
enable it there too, but we keep the legacy AIC IPI codepath in case
it is useful for backporting to older chips.

This also adds support for multi-die AIC2 controllers. While no
multi-die products exist yet, the AIC2 in t600x is built to support
up to 2 dies, and it's pretty clear how it works, so let's implement
it. If we're lucky, when multi-die products roll around, this will
let us support them with only DT changes. In order to support the
extra die dimension, this introduces a 4-argument IRQ phandle form
(3-argument is always supported and just implies die 0).

All register offsets are computed based on capability register values,
which should allow forward-compatibility with future AIC2 variants...
except for one. For some inexplicable reason, the number of actually
implemented die register sets is nowhere to be found (t600x has 2,
but claims 1 die in use and 8 dies max, neither of which is what we
need), and this is necessary to compute the event register offset,
which is page-aligned after the die register sets. We have no choice
but to split this out in the device tree as its own reg entry. Apple
also specify this offset in their ADT explicitly...

Changes since v2:
- Changed the DT binding to move the event register to its own reg entry
- Minor error cleanup rework in patch 7

Hector Martin (7):
  PCI: apple: Change MSI handling to handle 4-cell AIC fwspec form
  dt-bindings: interrupt-controller: apple,aic2: New binding for AICv2
  irqchip/apple-aic: Add Fast IPI support
  irqchip/apple-aic: Switch to irq_domain_create_tree and sparse hwirqs
  irqchip/apple-aic: Dynamically compute register offsets
  irqchip/apple-aic: Support multiple dies
  irqchip/apple-aic: Add support for AICv2

 .../interrupt-controller/apple,aic2.yaml      |  98 ++++
 MAINTAINERS                                   |   2 +-
 drivers/irqchip/irq-apple-aic.c               | 459 ++++++++++++++----
 drivers/pci/controller/pcie-apple.c           |   2 +-
 4 files changed, 473 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml

Comments

Alyssa Rosenzweig March 9, 2022, 8:30 p.m. UTC | #1

> This also adds support for multi-die AIC2 controllers. While no
> multi-die products exist yet, the AIC2 in t600x is built to support
> up to 2 dies, and it's pretty clear how it works, so let's implement
> it. If we're lucky, when multi-die products roll around, this will
> let us support them with only DT changes. In order to support the
> extra die dimension, this introduces a 4-argument IRQ phandle form
> (3-argument is always supported and just implies die 0).

Given you have a multidie device in the mail, it's probably best to
defer merging this series until the multidie code paths are confirmed
working there?

Marc Zyngier March 9, 2022, 8:37 p.m. UTC | #2

On 2022-03-09 20:30, Alyssa Rosenzweig wrote:
>> This also adds support for multi-die AIC2 controllers. While no
>> multi-die products exist yet, the AIC2 in t600x is built to support
>> up to 2 dies, and it's pretty clear how it works, so let's implement
>> it. If we're lucky, when multi-die products roll around, this will
>> let us support them with only DT changes. In order to support the
>> extra die dimension, this introduces a 4-argument IRQ phandle form
>> (3-argument is always supported and just implies die 0).
> 
> Given you have a multidie device in the mail, it's probably best to
> defer merging this series until the multidie code paths are confirmed
> working there?

This code is used on Pro and Max systems, so it has some value as is.
Not to mention that it makes things slightly faster on the original M1
too.

         M.