RE: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent node compatibles and refine documentation

Subject: RE: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent
node compatibles and refine documentation

quoted

Subject: Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed:
Add parent node compatibles and refine documentation

On 22/07/2025 11:51, Ryan Chen wrote:

quoted

The AST2700 SoC contains two independent top-level interrupt
controllers
(INTC0 and INTC1), each responsible for handling different
peripheral groups and occupying separate register spaces. Above
them, PSP(CA35) GIC controller acts as the root interrupt
aggregator. Accurately describing this hierarchical hardware
structure in the device tree requires distinct compatible strings for the parent

nodes of INTC0 and INTC1.

quoted

quoted

- Adds 'aspeed,ast2700-intc0' and 'aspeed,ast2700-intc1' compatible
strings for parent interrupt controller nodes. (in addition to the
existing 'aspeed,ast2700-intc-ic' for child nodes)

I don't understand how this solves your problem at all. Look at old
diagram - is it correct? If not, what makes you think that new diagram is

correct?

quoted

What is the meaning of existing binding and existing intc-ic compatible?

The new parent nodes (aspeed,ast2700-intc0/intc1) make the device tree layout
match the actual hardware separation shown in the SoC datasheet.
This allows us to register the full resource region, allocate platform resources
properly, and cleanly extend/debug in the future.

The previous "aspeed,ast2700-intc-ic" compatible only describes the interrupt
controller instance, not the full register block. In practice, with only a single child
node, there is no way to:
map and manage the entire address space for each INTC block (0x12100000 and
0x14c18000), or cleanly expose debug features that must access
routing/protection registers outside the intc-ic range.

The old diagram was incomplete, since it implied that the interrupt controller
block had only the intc-ic instance, but in hardware each INTC region contains
multiple functions and register ranges.

This binding change is mainly for clarity and correctness, aligning DT and driver
with the real SoC register map and future-proofing for debug/maintenance.

quoted

quoted

- Clarifies the relationship and function of INTC0 parent
 (intc0_0~x: child), INTC1 parent (intc1_0~x: child), and the GIC
in the documentation.
- Updates block diagrams and device tree examples to illustrate  the
hierarchy and compatible usage.
- Refines documentation and example formatting.

This change allows the device tree and driver to distinguish between
parent (top-level) and child (group) interrupt controller nodes,
enabling more precise driver matching SOC register space allocation.

And how it was not possible before? That's poor argument especially
that DT does not have to ever distinguish that.

Hi Krzysztof,

I wanted to follow up on my previous explanation about separating parent and child nodes for AST2700 INTC in the device tree.
There is other SoCs, such as Marvell’s CP110 ICU, also use a similar approach to separate parent controller and functional child nodes in the device tree, as shown here:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/interrupt-controller/marvell%2Ccp110-icu.yaml#L74-L98
Do you need me to provide further details or additional about our SOC design information?
Or is there anything specific you’d like clarified regarding the motivation or the binding structure?

Thanks for your feedback and guidance.

Best regards,
Ryan

quoted

Best regards,
Krzysztof