[PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent node compatibles and refine documentation
Ryan Chen
ryan_chen at aspeedtech.com
Sat Jul 26 18:47:34 PDT 2025
> Subject: Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent
> node compatibles and refine documentation
>
> On 23/07/2025 10:08, Ryan Chen wrote:
> >> 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:
> >>> + INTC0 is used to assert GIC if interrupt in INTC1 asserted.
> >>> + INTC1 is used to assert INTC0 if interrupt of modules asserted.
> >>> + +-----+ +---------+
> >>> + | GIC |---| INTC0 |
> >>> + +-----+ +---------+
> >>> + +---------+
> >>> + | |---module0
> >>> + | INTC0_0 |---module1
> >>> + | |---...
> >>> + +---------+---module31
> >>> + |---.... |
> >>> + +---------+
> >>> + | | +---------+
> >>> + | INTC0_11| +---| INTC1 |
> >>> + | | +---------+
> >>> + +---------+ +---------+---module0
> >>> + | INTC1_0 |---module1
> >>> + | |---...
> >>> + +---------+---module31
> >>> + ...
> >>> + +---------+---module0
> >>> + | INTC1_5 |---module1
> >>> + | |---...
> >>> + +---------+---module31
> >>
> >> You binding also said intc1 is the parent of intc-ic, so where is here intc-ic?
> >>
> >> This diagram and new binding do not match at all.
> >
> > The corresponded compatible is following.
> >
> > +-----+ +---------+
> > | GIC |---| INTC0 | -> (parent : aspeed,ast2700-intc0)
> > +-----+ +---------+
> > +---------+
> > | |---module0
> > | INTC0_0 |---module1
> > (child : aspeed,ast2700-intc-ic)
> > | |---...
> > +---------+---module31
> > |---.... |
> > +---------+
> > | | +---------+
> > | INTC0_11 | +---------------------------- | INTC1 | -> ->
> (parent : aspeed,ast2700-intc1)
>
> AGAIN (second time): that's not what your binding said.
>
> Your binding is explicit here, which is what we want in general. It says that inct1 is
> one of the parents of intc-ic.
>
> Let me be clear, because you will be dragging this talk with irrelevant arguments
> forever - changing this binding is close to no. If you come with correct arguments,
> maybe would work. But the main point is that you probably do not have to even
> change the binding to achieve proper hardware description. Work on that.
>
If I do not change the binding, I think the yaml and dts can still fit the interrupt
nesting architecture by using both interrupts and interrupts-extended.
For first-level controllers, use the standard interrupts property
(e.g. with the GIC as the parent).
For second-level INTC-IC instances, use interrupts-extended to refer to the
first-level INTC-IC, following common Linux practice for stacked interrupt controllers.
For example:
dts
// First level
intc0_11: interrupt-controller at 12101b00 {
compatible = "aspeed,ast2700-intc-ic";
reg = <...>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, ...;
};
// Second level, cascaded
intc1_0: interrupt-controller at 14c18100 {
compatible = "aspeed,ast2700-intc-ic";
reg = <...>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts-extended = <&intc0_11 0 IRQ_TYPE_LEVEL_HIGH>;
};
In yaml, I can use:
oneOf:
- required: [interrupts]
- required: [interrupts-extended]
This allows both cases to be valid.
Please let me know if this is the recommended approach,
or if further changes are needed.
> Best regards,
> Krzysztof
More information about the linux-arm-kernel
mailing list