[PATCH v4 1/2] dt-bindings: interrupt-controller: aspeed: Add parent compatibles and refine documentation
Andrew Jeffery
andrew at codeconstruct.com.au
Tue Sep 9 18:41:19 AEST 2025
On Thu, 2025-08-14 at 10:03 +0200, Krzysztof Kozlowski wrote:
> On Tue, Aug 12, 2025 at 06:08:29PM +0800, Ryan Chen wrote:
> > AST2700 contains two independent top-level interrupt controllers (INTC0,
> > INTC1). Each occupies its own register space and handles different sets of
> > peripherals. Above them, the PSP (CA35) GIC is the root interrupt
> > aggregator. In hardware, INTC1 outputs are routed into INTC0, and INTC0
> > outputs are routed into the GIC.
> >
> > Introduce distinct compatibles for these parent blocks so the DT can model
> > the hierarchy and register space layout accurately:
> >
> > - aspeed,ast2700-intc0 (parent node at 0x12100000)
> > - aspeed,ast2700-intc1 (parent node at 0x14c18000)
> >
> > The existing child compatible:
> >
> > - aspeed,ast2700-intc-ic
> >
> > continues to describe the interrupt-controller instances within each INTC
> > block (e.g. INTC0_0..INTC0_11 and INTC1_0..INTC1_5).
> >
> > Signed-off-by: Ryan Chen <ryan_chen at aspeedtech.com>
> > ---
> > .../aspeed,ast2700-intc.yaml | 158 +++++++++++++-----
> > 1 file changed, 115 insertions(+), 43 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-
> > controller/aspeed,ast2700-intc.yaml
> > b/Documentation/devicetree/bindings/interrupt-
> > controller/aspeed,ast2700-intc.yaml
> > index 55636d06a674..81304b53c112 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml
> > @@ -10,6 +10,33 @@ description:
> > This interrupt controller hardware is second level interrupt controller that
> > is hooked to a parent interrupt controller. It's useful to combine multiple
> > interrupt sources into 1 interrupt to parent interrupt controller.
> > + Depend to which INTC0 or INTC1 used.
> > + INTC0 and INTC1 are two kinds of interrupt controller with enable and raw
> > + status registers for use.
> > + INTC0 is used to assert GIC if interrupt in INTC1 asserted.
> > + INTC1 is used to assert INTC0 if interrupt of modules asserted.
> > + +-----+ +---------+
> > + | GIC |---| INTC0 |
> > + +-----+ +---------+
>
> Same problem as last time. This tells me intc0 has not children...
>
> > + +---------+
> > + | |---module0
> > + | INTC0_0 |---module1
> > + | |---...
> > + +---------+---module31
> > + |---.... |
> > + +---------+
> > + | | +---------+
> > + | INTC0_11| +---| INTC1 |
> > + | | +---------+
>
> ...This tells that inc1 has no children (only intc0_11, which you said
> is aspeed,ast2700-intc-ic !!!)....
> (keep scrolling)
>
> > + +---------+ +---------+---module0
> > + | INTC1_0 |---module1
> > + | |---...
> > + +---------+---module31
> > + ...
> > + +---------+---module0
> > + | INTC1_5 |---module1
> > + | |---...
> > + +---------+---module31
> >
I've taken a look at the datasheet and had a bit of a think about how
to make progress here.
My feeling is this diagram (and the previous one) undersells the
complexity of the design by quite some margin. It's probably best to
start by zooming out quite a lot:
The AST2700 SoC contains (at least) 4 distinct processors:
1. The quad-core ARM Cortex-A35 (PSP: Primary Service Processor)
2. A Cortex-M4 (SSP: Secondary Service Processor)
3. Another Cortex-M4 (TSP: Tertiary Service Processor)
4. The BootMCU - a RISC-V processor to execute the mask ROM
While the PSP GIC shown in the diagram above is one possible interrupt
destination, many of the 480 interrupt sources in the package can be
routed to the dedicated interrupt controller of any of these four
processors. Likewise, many peripherals of the SoC are mapped into the
physical address space of each processor. The routing is handled by the
two interrupt controller blocks described in the binding text above:
+--------------------+
| +-------+ +------+ |
| | | | | |
| | PSP +-+ GIC <-+----------+
| | | | | | |
| +-------+ +------+ | |
+--------------------+ |
|
+--------------------+ |
| +-------+ +------+ | | +-------+
| | | | | | | | | INTx
| | SSP +-+ NVIC <-+----------+----------| INTC0 <-----------
| | | | | | | | |
| +-------+ +------+ | | +---^---+
+--------------------+ | |
| |
+--------------------+ | |
| +-------+ +------+ | | |
| | | | | | | |
| | TSP +-+ NVIC <-+----------+ |
| | | | | | |
| +-------+ +------+ | |
+--------------------+ |
|
+--------------------+ |
| +------+ +-------+ | +---+---+
| | | | | | | | INTy
| | BMCU +-+ APLIC <-+---------------------+ INTC1 <-----------
| | | | | | | |
| +------+ +-------+ | +-------+
+--------------------+
There's a split in the interrupt domain: 0 <= INTx <= 127 < INTy.
The PSP GIC, SSP NVIC and TSP NVIC destinations for each INTx source is
selected by a corresponding mux in INTC0.
The destination for each INTy source is selected by a corresponding mux
in INTC1, where the possible destinations are:
1. A shared interrupt line Ma, routed through INTC0 to the PSP GIC
2. A mux in INTC0, providing a second level of indirection
3. A shared interrupt line Md, routed through INTC0 to the PSP GIC
4. A shared interrupt line Me, routed through INTC0 to the PSP GIC
5. A shared interrupt line Mb, routed through INTC0 to the SSP NVIC
6. A shared interrupt line Mc, routed through INTC0 to the TSP NVIC
7. The BootMCU APLIC
Each shared interrupt line from INTC1 to INTC0 merges up to 32
interrupt sources.
INTC0 and INTC1 are both mapped into the physical address space of each
processor. However, to prevent any one of them interfering with
interrupts dedicated to another, the controller's register map is
divided into distinct regions whose access is constrained to a specific
processor. The enable and status registers in INTC0 for shared line
sets Ma, Md and Me are constrained to the PSP, Mb to the SSP, and Mc to
the TSP.
+-------+ +-------+
| INTC0 | | INTC1 |
- - - - - - - - - - - - - - - - - -+- - - -+- - - - - - +- - - -+- -
+--------------------+ | | | |
| +-------+ +------+ | | | | |
| | | | | | | | | |
| | PSP +-+ GIC | | | | | |
| | | | | | | | | |
| +-------+ | | | | | | |
| | | | +-------+ | |
| | 192 <-|-----------+ Ma <------------|---+ |
| | | | +-------+ | | |
| | 208 <-|-----------+ Md <------------|---+ |
| | | | +-------+ | | |
| | 224 <-|-----------+ Me <------------|---+ |
| | | | +-------+ | | |
| +------+ | | | | | |
+--------------------+ | | | | |
- - - - - - - - - - - - - - - - - -+- - - -+- - - - - - +- -|- -+- -
+--------------------+ | | | | |
| +-------+ +------+ | +-------+ | +---|------------
| | SSP +-+ NVIC <-|-----------+ Mb <------------|---+ | INT128
| +-------+ +------+ | +-------+ | | |
+--------------------+ | | | | |
- - - - - - - - - - - - - - - - - -+- - - -+- - - - - - +- -|- -+- -
+--------------------+ | | | | |
| +-------+ +------+ | +-------+ | | |
| | TSP +-+ NVIC <-|-----------+ Mc <------------|---+ |
| +-------+ +------+ | +-------+ | |
+--------------------+ | | | |
- - - - - - - - - - - - - - - - - -+- - - -+- - - - - - +- - - -+- -
+--------------------+ | | | |
| +------+ +-------+ | | | | |
| | BMCU +-+ APLIC | | | | | |
| +------+ +-------+ | | | | |
+--------------------+ | | | |
- - - - - - - - - - - - - - - - - -+- - - -+- - - - - - +- - - -+- -
+-------+ +-------+
INTC1 mux destination 2 above allows the PSP to reconfigure the routes
at runtime at INTC0, rather than submit to a route that might've been
protected by firmware early in the boot chain, so long as the boot
firmware chose the appropriate route in INTC1. INTC0 merges these
interrupts in sets of 32 and operates in much the same way as INTC1 in
the diagram above, though cannot route to the BootMCU.
I'd prefer we acknowledge all this in the binding, and do enough to
allow the kernel to configure routing as it wishes. While in some
applications the routes may be constrained by firmware, the platform-
specific portion of the devicetree can be written reflect this.
More information about the Linux-aspeed
mailing list