dts: unable to access the interrupt controller in interrupts-extended

[ycsin]

Is your enhancement proposal related to a problem? Please describe.
As things stand today, there is no way for a driver to know it's parent interrupt controller if it is specified in the interrupts-extended instead of the interrupt-parent property.

For example, we can get the interrupt controller of a uart node can easily:

zephyr/dts/riscv/virt.dtsi

Lines 27 to 34 in 6e678e3

	uart0: uart@10000000 {
	interrupts = < 0x0a 1 >;
	interrupt-parent = < &plic >;
	clock-frequency = < 0x384000 >;
	reg = < 0x10000000 0x100 >;
	compatible = "ns16550";
	reg-shift = < 0 >;
	};

with:

DT_PROP(DT_NODELABEL(uart0), interrupt_parent)

but there's no way to get the interrupt controller for the following node:

zephyr/dts/riscv/virt.dtsi

Lines 165 to 183 in 6e678e3

	plic: interrupt-controller@c000000 {
	riscv,max-priority = <7>;
	riscv,ndev = < 1024 >;
	reg = <0x0c000000 0x04000000>;
	interrupts-extended = <
	&hlic0 0x0b &hlic0 0x09
	&hlic1 0x0b &hlic1 0x09
	&hlic2 0x0b &hlic2 0x09
	&hlic3 0x0b &hlic3 0x09
	&hlic4 0x0b &hlic4 0x09
	&hlic5 0x0b &hlic5 0x09
	&hlic6 0x0b &hlic6 0x09
	&hlic7 0x0b &hlic7 0x09
	>;
	interrupt-controller;
	compatible = "sifive,plic-1.0.0";
	#address-cells = < 0x00 >;
	#interrupt-cells = < 0x02 >;
	};

Even though the devicetree has all the info about the hardware, the application has no way to tap to those info. Having such ability would be able to simplify the generation of the lookup table for multi-level interrupt controllers, see multilevel_irq.c.

Describe the solution you'd like
Output the interrupt controller node(s) in the interrupts-extended properties, alongside with the interrupt number and priority if available.

Additional context

• Docs: Specifying interrupt information for devices
• arch: common: multilevel irq: fix issues where the intc device is NULL #65288 (comment)

[nordicjm]

Isn't this related to what @bjarki-trackunit explained on this weeks architecture working group call?

[ycsin]

Isn't this related to what @bjarki-trackunit explained on this weeks architecture working group call?

Not really sure what's discussed in the meeting, is there a pointer to that?

[nordicjm]

Isn't this related to what @bjarki-trackunit explained on this weeks architecture working group call?

Not really sure what's discussed in the meeting, is there a pointer to that?

#66505

[bjarki-andreasen]

Hi, this is in fact part of that PR, there are a few commits which update gen_defines.py and add the required macros to get the interrupt controller as specified by the devicetree section 2.4.1

See the additions to devicetree.h (DT_INTC(node_id) etc.) :)

[ycsin]

Hi, this is in fact part of that PR, there are a few commits which update gen_defines.py and add the required macros to get the interrupt controller as specified by the devicetree section 2.4.1

See the additions to devicetree.h (DT_INTC(node_id) etc.) :)

Just had a look at the (updated) RFC, seems like I could have sit back and relax!
In any case I think changes to the gen_defines.py and devicetree.h can be spin-off into a separate PR

[bjarki-andreasen]

Hi, this is in fact part of that PR, there are a few commits which update gen_defines.py and add the required macros to get the interrupt controller as specified by the devicetree section 2.4.1

See the additions to devicetree.h (DT_INTC(node_id) etc.) :)

Just had a look at the (updated) RFC, seems like I could have sit back and relax!
In any case I think changes to the gen_defines.py and devicetree.h can be spin-off into a separate PR

agreed, I will split it into its own PR shortly :)