dts: pm: Add wakeup-signal property

[mmahadevan108]

This is a new property to specify the wakeup signal number. There are some SoC's where the wakeup signal can be a different signal and not necessarily the interrupt number.
This property goes together with wakeup-source.

[decsny]

what would be the actual usage paradigm of this value?

[mbolivar]

I have the same question as @decsny . It feels like this is something that probably belongs in interrupts. The commit message doesn't make the example clear, but if the issue is that the "handler" for the wakeup signal is different than the interrupt controller for the "normal" interrupt in the IP blocks you're looking at, then I think this is probably a use case for interrupts-extended -- see the DT spec.

[mmahadevan108]

@mbolivar @decsny thanks for looking at the PR. I have added a commit to provide some context on why this property was added.
@mbolivar I was not aware of the interrupts-extended property. Based on the use-case I provided, do you think this is the approach we should explore?

[mbolivar]

@mmahadevan108 what hardware is responsible for handling the wakeup event? Is this a cortex M where it eventually has to go through the NVIC?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[DerekSnell]

what hardware is responsible for handling the wakeup event? Is this a cortex M where it eventually has to go through the NVIC?

Hi @mbolivar ,
The MCXW71 and many other NXP SOCs have a hardware module called a Wake-Up Unit (WUU). The WUU is used when the core digital domain is in a static state or is powered off, which includes the NVIC. The wakeup-signal Mahesh is enabling for the LPTMR is an input to the WUU. Frequently a WUU wake-up will eventually be handled by the NVIC as an interrupt. Depending on the peripheral triggering the WUU, the NVIC may not see an IRQ from that peripheral. It may only see the IRQ from the WUU, and would use this wakeup-signal number to determine which handler to call.

But the WUU does support other use-cases that do not involve interrupts. The MCXW71 and other NXP SOC support partial wake-up, where the CPU remains clock gated and an interrupt is not triggered during the wake-up. An example is a UART could receive a byte, trigger a partial wake-up, and activate the DMA. The DMA copies the byte to a buffer and then the SOC returns to the previous low-power mode without interrupting the CPU. After enough iterations, the DMA will trigger an interrupt and wake the CPU. But then the interrupt handler is for the DMA, and unrelated to the WUU wake-up signal or the UART.

I'm not sure if this explanation helps with this property discussion. Is there more I can help with? Thanks

[decsny]

There is not enough value proposition being shown here to justify to be adding this property IMO. You are providing this value to a vendor specific macro. If we add this property it will become sticky and if people start using it and it turns out not to be very useful and becomes a technical debt when we decide some other way to do something, I don't want to add it. It's not thought through and seems rushed, and for what goal exactly I don't quite understand, I'm not seeing what it buys us.

[decsny]

Also I can see it being fulfilled more generically and doing away with this vendor macro by my #93838 if you think of it as a one bit multiplexor

[mbolivar]

@DerekSnell I appreciate the explanation, thanks.

From what you have said, my instincts would be to model the WUU as a devicetree interrupt controller, and treat peripherals that are capable of asynchronously signaling the WUU on an event as interrupt-generating devices whose interrupts are handled by the WUU node. If they can also generate interrupts that go to the NVIC, that is a use case for interrupts-extended. The fact that the WUU can in turn interrupt the NVIC is already supported by zephyr's multi-level interrupt infrastructure as far as I can see.

Please see section 2.4 in the devicetree specification if you are unfamiliar with the details on how interrupts work in DT.

Of course, see https://docs.zephyrproject.org/latest/kernel/services/interrupts.html for details on the interrupt controller hierarchy in zephyr.

See https://github.com/zephyrproject-rtos/zephyr/tree/main/dts/riscv/openisa for some in-tree examples of SoCs that stitch all this together in DT, and you can grep around in the sources to see example drivers that use these multi level IRQ controller nodes in practice.

If there is really something missing here in the existing interrupt handling infrastructure that you can articulate after familiarizing yourself with the DT and Zephyr standard way of doing this, please let me know and we can continue discussion. Absent something convincing, though, this PR feels like it's reinventing the wheel.

[decsny]

I did not know the WUU actually has an interrupt to the NVIC of it's own, so I can see how that leads down the thought path of model it as a multi level interrupt control. But as far as I can tell there is no standardized interrupt interface of zephyr, all the interrupt controller drivers are vendor specific interfaces... But I guess what this would end up being is that instead of us having this NXP_ENABLE_WAKEUP_SIGNAL macro (which is defined in SOC.h) to enable wakeups, instead we have a SOC-specific wrapper function (also from soc.h) called here (nxp_enable_wakeup_signal, if you will), which is implemented by calling on whichever interrupt controller driver is used with the platform to handle the wakeups signals, and registers a callback and all this stuff ...