dts: renesas: ra: Handle interrupt numbers generation for Renesas RA series

[quytranpzz]

This PR updates interrupt number for Renesas RA boards (for current supported boards, RA2L1 will be supported later) to avoid full of interrupt ID.
(related to PR #78579).
We will add map_renesas_ra_irq function in gen_defines.py script to intervene in the generation of the device tree during build.
Only nodes with status = "okay"; will have their interrupt IDs generated as valid numbers in devicetree_generated.h. The others will be assigned interrupt IDs with the unspecified value (0xff).
This will help conserve the interrupt IDs allocated in isr_table.c.

[bjarki-andreasen]

As discussed at length in #75946 and at the arch meeting, interrupt maps in the devicetree shall be used for mapping interrupts. I see there is some precedence with the map_arm_gic_irq_type fn, but as the TODO just above the function suggests, this should be moved to the devicetree as well.

[thaoluonguw]

As discussed at length in #75946 and at the arch meeting, interrupt maps in the devicetree shall be used for mapping interrupts. I see there is some precedence with the map_arm_gic_irq_type fn, but as the TODO just above the function suggests, this should be moved to the devicetree as well.

@bjarki-andreasen: We aware the discussion in #75946.

• As you may already know, the RA MCU interrupt mapping is complicated. The mapping can be up to 400+ signals map with 96 NVIC lines. Your proposal for using interrupt_map is almost impossible for RA Zephyr Users.

• With this situation, we would like to propose a solution to support for RA Zephyr but not impact to others in Zephyr ecosystem. It is supported for RA MCU specifically. We would like to have your strongly consideration to have a change to improve for RA Zephyr User Experience.

Thank you so much.

[bjarki-andreasen]

As discussed at length in #75946 and at the arch meeting, interrupt maps in the devicetree shall be used for mapping interrupts. I see there is some precedence with the map_arm_gic_irq_type fn, but as the TODO just above the function suggests, this should be moved to the devicetree as well.

@bjarki-andreasen: We aware the discussion in #75946.

• As you may already know, the RA MCU interrupt mapping is complicated. The mapping can be up to 400+ signals map with 96 NVIC lines. Your proposal for using interrupt_map is almost impossible for RA Zephyr Users.
• With this situation, we would like to propose a solution to support for RA Zephyr but not impact to others in Zephyr ecosystem. It is supported for RA MCU specifically. We would like to have your strongly consideration to have a change to improve for RA Zephyr User Experience.

Thank you so much.

The effect in the Zephyr ecosystem will not be felt heavily by this addition specifically, it will be felt when others want to do the same. The gen_defines.py script will, with high certainty, be abused. Add a little here for one platform, a little there for another, until any change to introduce new platforms, or make changes to the overall interrupt architecture becomes impossible without breaking existing platforms.

A platform, redefining what an IRQ number is, how IRQs are modeled in the devicetree, how the isr table is generated, which is different from all other platforms, is not scalable. The solution in this PR, is not scalable.

The learning curve for any OS is already high, now users need to learn how each platform implements and manages interrupts?

The fact is that we have a solution for interrupt mapping, which supports all platforms, including this one. It may not be perfectly tailored to the RA (I believe it is fine), but that is the case for any standard.

[thaoluonguw]

As discussed at length in #75946 and at the arch meeting, interrupt maps in the devicetree shall be used for mapping interrupts. I see there is some precedence with the map_arm_gic_irq_type fn, but as the TODO just above the function suggests, this should be moved to the devicetree as well.

@bjarki-andreasen: We aware the discussion in #75946.

• As you may already know, the RA MCU interrupt mapping is complicated. The mapping can be up to 400+ signals map with 96 NVIC lines. Your proposal for using interrupt_map is almost impossible for RA Zephyr Users.
• With this situation, we would like to propose a solution to support for RA Zephyr but not impact to others in Zephyr ecosystem. It is supported for RA MCU specifically. We would like to have your strongly consideration to have a change to improve for RA Zephyr User Experience.

Thank you so much.

The effect in the Zephyr ecosystem will not be felt heavily by this addition specifically, it will be felt when others want to do the same. The gen_defines.py script will, with high certainty, be abused. Add a little here for one platform, a little there for another, until any change to introduce new platforms, or make changes to the overall interrupt architecture becomes impossible without breaking existing platforms.

A platform, redefining what an IRQ number is, how IRQs are modeled in the devicetree, how the isr table is generated, which is different from all other platforms, is not scalable. The solution in this PR, is not scalable.

The learning curve for any OS is already high, now users need to learn how each platform implements and manages interrupts?

The fact is that we have a solution for interrupt mapping, which supports all platforms, including this one. It may not be perfectly tailored to the RA (I believe it is fine), but that is the case for any standard.

Thanks @bjarki-andreasen for your explanation, we understood the situation. We will consider design policy again and improve for user experience in documentations. Thank you again.

[quytranpzz]

This PR is no longer active, so I'd like to close it. Thanks so much for the explanation @bjarki-andreasen