On 27/07/2025 03:47, Ryan Chen wrote:

quoted

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:

quoted

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

+  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.

... and you never addressed that. :/

quoted

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@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@14c18100 {
    compatible = "aspeed,ast2700-intc-ic";
    reg = <...>;
    interrupt-controller;
    #interrupt-cells = <2>;
    interrupts-extended = <&intc0_11 0 IRQ_TYPE_LEVEL_HIGH>;

This looks like changing the meaning of the interrupt. What was the
interrupt here before? What interrupt is here now?

};
In yaml, I can use:
oneOf:
  - required: [interrupts]
  - required: [interrupts-extended]
This allows both cases to be valid.

Hm? Since when you need both cases?


Best regards,
Krzysztof