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

[Krzysztof Kozlowski]

On 25/07/2025 09:18, Ryan Chen wrote:
> 
>> Subject: 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
>>>
>>> On 22/07/2025 11:51, Ryan Chen wrote:
>>>> 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.
>>>>
>>>> - 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?
>>>
>>> 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.
>>>
>>>> - 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?

Start properly wrapping your email responses. All of them are
misformatted, all the time!

You got replies from two DT binding maintainers. Work with that.

Best regards,
Krzysztof