Add support for arbitrary PM constraint lists from DT and substate change notifier, refactor RW612 power domain

[decsny]

Cherry-picked the RW612 DTS refactor from #89372 and realized it causes runtime failures due to for example the flexcomm driver is trying to use the pm_policy_device_is_disabling_state API which stops working if the disabling state is not directly defined on the device's node and is defined on the parent instead, so fix this in the policy_device_lock.c by checking first parent domain constraints

[bjarki-andreasen]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

[decsny]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.

For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.

And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.

And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

[bjarki-andreasen]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.

For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.

And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.

And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

I think the "child" device should just have the disabling states duplicated. Its not actually a child device of the power domain if it does not rely on the parent power domain for managing the soc states. If the parent power domain was used, the soc would never enter a disabling state while the child device is resumed, the power domain would inform the child device that an disabling state may be entered by the TURN_OFF action.

[decsny]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.
For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.
And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.
And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

I think the "child" device should just have the disabling states duplicated. Its not actually a child device of the power domain if it does not rely on the parent power domain for managing the soc states. If the parent power domain was used, the soc would never enter a disabling state while the child device is resumed, the power domain would inform the child device that an disabling state may be entered by the TURN_OFF action.

Okay I considered just doing this but IMO this is what is the layering violation because now it needs to be known by whoever is writing that DT that this device driver has some special implementation that requires this property to be set on it's own node even though the information is redundant with the fact that obviously it would be disabled on a state that also disables the power-domain parent. And on top of this , the device driver implementation is not supposed to be special, it's using a generic subsystem API, which is not acting as expected IMO if it doesn't say for child devices that they will get disabled by a state that disables their power domain.

[bjarki-andreasen]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.
For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.
And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.
And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

I think the "child" device should just have the disabling states duplicated. Its not actually a child device of the power domain if it does not rely on the parent power domain for managing the soc states. If the parent power domain was used, the soc would never enter a disabling state while the child device is resumed, the power domain would inform the child device that an disabling state may be entered by the TURN_OFF action.

Okay I considered just doing this but IMO this is what is the layering violation because now it needs to be known by whoever is writing that DT that this device driver has some special implementation that requires this property to be set on it's own node even though the information is redundant with the fact that obviously it would be disabled on a state that also disables the power-domain parent. And on top of this , the device driver implementation is not supposed to be special, it's using a generic subsystem API, which is not acting as expected IMO if it doesn't say for child devices that they will get disabled by a state that disables their power domain.

The device would also obviously be disabled by the disabling states of the power domains parent power domain, and that grandparents power domain, are we going to store those with the device to? Power domains already solve this issue by walking up the chain. If this driver wants to do something different from what is already supported, then it is special, and it should be treated specially. This is not an issue common to the power management subsystem given we have support for power domains right?

[decsny]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.
For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.
And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.
And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

I think the "child" device should just have the disabling states duplicated. Its not actually a child device of the power domain if it does not rely on the parent power domain for managing the soc states. If the parent power domain was used, the soc would never enter a disabling state while the child device is resumed, the power domain would inform the child device that an disabling state may be entered by the TURN_OFF action.

Okay I considered just doing this but IMO this is what is the layering violation because now it needs to be known by whoever is writing that DT that this device driver has some special implementation that requires this property to be set on it's own node even though the information is redundant with the fact that obviously it would be disabled on a state that also disables the power-domain parent. And on top of this , the device driver implementation is not supposed to be special, it's using a generic subsystem API, which is not acting as expected IMO if it doesn't say for child devices that they will get disabled by a state that disables their power domain.

The device would also obviously be disabled by the disabling states of the power domains parent power domain, and that grandparents power domain, are we going to store those with the device to? Power domains already solve this issue by walking up the chain.

To be clear, this PR already does handle arbitrary amounts of grandparents, what it does is it goes until it finds the first node that has this zephyr,disabling-power-states property and uses that.

If this driver wants to do something different from what is already supported, then it is special, and it should be treated specially. This is not an issue common to the power management subsystem given we have support for power domains right?

The driver is not doing anything special, it's just using the API which I linked above. Which when I do this DTS refactor causes the driver to get told false when asking if any particular power state will disable it, even though many will actually will disable it. So in my view there is only two reasonable options here that are consistent:

1. Allow this API https://docs.zephyrproject.org/latest/doxygen/html/group__subsys__pm__sys__policy.html#ga4cfc3c450387663b6e1bf9bb966baad8 to actually check the parent domains if the device doesn't explicitly say it's own disabling states, so that it returns a reasonably correct value (otherwise, if it doesn't have this property, but is on any domain which gets disabled by certain modes, then it will ALWAYS return the wrong value saying that no state will ever disable it, which is not correct
2. Make a statement to say that all PM-managed devices must declare their zephyr,disabling-power-states explicitly and directly on their corresponding DT node, no exceptions, otherwise, it gets out of control fast for DTS writers to be able to know which drivers and devices have a dependency to expect this property or not based on their implementation (which again, is NOT doing something "special", it's just using the pm subsys api to ask a simple question of will I get disabled or not, yes or no)

[bjarki-andreasen]

Child devices will resume their power domain, and the power domain locks the state. In which scenarios would the child device lock a state of another device? seems like a strong layering violation to have devices look into implementation details of other devices instead of just resuming them, which causes other devices to lock their states already (or do whatever they need to to remain powered)

You are right, but my intention though was not about actually changing what states are locked, but mostly the issue is related to this pm_policy_device_lock_is_disabling_state which now if the DTS is refactored so that the parent domain is has that info, then the function doesnt return the right value (true/false) for the child.
For example if the parent will be disabled by a mode "suspend", then the child also obviously would be disabled by this mode "suspend" even if zephyr,disabling-states is not present on the child but only on the parent. So currently that function which only checks the zephyr,disabling-states that is actually on the node for the device in question will return "false" for this child (saying it won't be disabled in "suspend") when in reality it will because it's power domain was disabled.
And to be clear, this is not changing anything if a device has this property already, only if it doesn't then it checks it's power domain parents based on the assumption that if the power domain parents are disabled then it will be too.
And beyond just checking if a state will disable a device, as far as the locking mechanism itself - I agree with you that how it's supposed to work is that the power domain parent (in this context) should be the one that locks from entering the state and then the other devices don't need to do this due to as long as one of them is referenced/active then the parent should remain active. I completely understand that and agree. So since my goal wasn't actually to change this locking mechanism, should I change this code to uncouple the pm_policy_device_lock_is_disabling_state to not use the same constraint searching code as the other functions in this file ? I.e, still adding the "special" value of 0 size to indicate to look at the parent device but don't actually do it from the locking functions and only from this checking function (pm_policy_device_lock_is_disabling_state)

I think the "child" device should just have the disabling states duplicated. Its not actually a child device of the power domain if it does not rely on the parent power domain for managing the soc states. If the parent power domain was used, the soc would never enter a disabling state while the child device is resumed, the power domain would inform the child device that an disabling state may be entered by the TURN_OFF action.

Okay I considered just doing this but IMO this is what is the layering violation because now it needs to be known by whoever is writing that DT that this device driver has some special implementation that requires this property to be set on it's own node even though the information is redundant with the fact that obviously it would be disabled on a state that also disables the power-domain parent. And on top of this , the device driver implementation is not supposed to be special, it's using a generic subsystem API, which is not acting as expected IMO if it doesn't say for child devices that they will get disabled by a state that disables their power domain.

The device would also obviously be disabled by the disabling states of the power domains parent power domain, and that grandparents power domain, are we going to store those with the device to? Power domains already solve this issue by walking up the chain.

To be clear, this PR already does handle arbitrary amounts of grandparents, what it does is it goes until it finds the first node that has this zephyr,disabling-power-states property and uses that.

If this driver wants to do something different from what is already supported, then it is special, and it should be treated specially. This is not an issue common to the power management subsystem given we have support for power domains right?

The driver is not doing anything special, it's just using the API which I linked above. Which when I do this DTS refactor causes the driver to get told false when asking if any particular power state will disable it, even though many will actually will disable it. So in my view there is only two reasonable options here that are consistent:

1. Allow this API https://docs.zephyrproject.org/latest/doxygen/html/group__subsys__pm__sys__policy.html#ga4cfc3c450387663b6e1bf9bb966baad8 to actually check the parent domains if the device doesn't explicitly say it's own disabling states, so that it returns a reasonably correct value (otherwise, if it doesn't have this property, but is on any domain which gets disabled by certain modes, then it will ALWAYS return the wrong value saying that no state will ever disable it, which is not correct
2. Make a statement to say that all PM-managed devices must declare their zephyr,disabling-power-states explicitly and directly on their corresponding DT node, no exceptions, otherwise, it gets out of control fast for DTS writers to be able to know which drivers and devices have a dependency to expect this property or not based on their implementation (which again, is NOT doing something "special", it's just using the pm subsys api to ask a simple question of will I get disabled or not, yes or no)

The API linked above is only used by one driver, and serves a niche purpose to accommodate pm device system managed. This PR is increasing the complexity of a part of device pm which we are actively working towards removing, pm device runtime and power domains already solves this issue, that's why I'm against this addition.

So, 1. is actively moving in a direction which goes against transitioning to pm device runtime to solve a short term issue. 2. is closer to the status quo, if an soc has states which disable it, the states are added to the device. The disabling states can be moved to a power domain negating the need to define the states for the device, which can be more efficient. Having a power domain, not using it, and also not defining the disabling state for the device, is a mistake on the part of the dts writer, we should not add what is effectively error handling to PM, its complex enough as is.

[decsny]

@bjarki-andreasen I think the confusion here is about why is this device needing to check on if it is a disabling state. Because the point is not to support/accommodate system managed device PM. IIRC, the reason is because this device and some others on this chip actually do not lose function in a low power mode, even if the "domain" suspends, they dont turn off and actually continue operating. But the issue with this chip is that there is not really a coherent concept of domains in the hardware like the zephyr architecture is meant for, it's just a bunch of barely documented behaviors that are seemingly different for each peripheral on the chip. Some of them lose state at certain power mode, some of them still function, some of them retain state but dont function.... and it's not configurable or clear why or how (we mostly are figuring it out by reverse engineering)...

So IIRC this UART is one of them that goes in a "low power" mode when system enters this "PM2" mode (associated to suspend in zephyr). In this case, the UART is not able to really do any send and transceive normally as far as I could tell but it could change clock source to some really slow like 1Hz clock which is the only one left active on the system in this mode, and be able to "receive" one bit/byte, and this activity can then be a wakeup cause of the chip. So what this driver is essentially saying is "if my normal function is going to be disabled, reconfigure my clock to the low power clock and configure me as wake up source" (zephyr,disabling-states). Whereas on "PM3" mode (associated to suspend), the UART just completely lose power and state and cannot be a wakeup. So we set the power-domain to this "PM3" domain which is currently just a stupid mechanism to be able to deliver an "OFF" action to all these devices which lose power and state from "standby" mode, and set "zephyr,disabling-states" as "suspend" (and standby technically, but irrelevant) so that it knows it loses function but can reconfigure itself as a wakeup...

So do you have any idea about how to handle this problem which is that our device cannot only just be simply "disabled" or "enabled" but can also be in this type of low power mode that it needs to account for? Because from PM device callbacks alone, it's not enough here to handle that "PM2" case, we can handle this PM3 case to get the OFF action and know we will lose state but I am not sure how to differentiate for the "low power operation" case

[decsny]

And by the way, I am noticing this is a pretty common thing for us too - for power domains and devices to have not just a binary on/off state but actually different levels of operation (low power modes). Right now we only enabled this uart driver for it's low power mode because we wanted the shell to keep working on PM2 since many of our wifi samples (RW612 is basically mainly a wifi chip) were based on a shell

[bjarki-andreasen]

@bjarki-andreasen I think the confusion here is about why is this device needing to check on if it is a disabling state. Because the point is not to support/accommodate system managed device PM. IIRC, the reason is because this device and some others on this chip actually do not lose function in a low power mode, even if the "domain" suspends, they dont turn off and actually continue operating. But the issue with this chip is that there is not really a coherent concept of domains in the hardware like the zephyr architecture is meant for, it's just a bunch of barely documented behaviors that are seemingly different for each peripheral on the chip. Some of them lose state at certain power mode, some of them still function, some of them retain state but dont function.... and it's not configurable or clear why or how (we mostly are figuring it out by reverse engineering)...

So IIRC this UART is one of them that goes in a "low power" mode when system enters this "PM2" mode (associated to suspend in zephyr). In this case, the UART is not able to really do any send and transceive normally as far as I could tell but it could change clock source to some really slow like 1Hz clock which is the only one left active on the system in this mode, and be able to "receive" one bit/byte, and this activity can then be a wakeup cause of the chip. So what this driver is essentially saying is "if my normal function is going to be disabled, reconfigure my clock to the low power clock and configure me as wake up source" (zephyr,disabling-states). Whereas on "PM3" mode (associated to suspend), the UART just completely lose power and state and cannot be a wakeup. So we set the power-domain to this "PM3" domain which is currently just a stupid mechanism to be able to deliver an "OFF" action to all these devices which lose power and state from "standby" mode, and set "zephyr,disabling-states" as "suspend" (and standby technically, but irrelevant) so that it knows it loses function but can reconfigure itself as a wakeup...

So do you have any idea about how to handle this problem which is that our device cannot only just be simply "disabled" or "enabled" but can also be in this type of low power mode that it needs to account for? Because from PM device callbacks alone, it's not enough here to handle that "PM2" case, we can handle this PM3 case to get the OFF action and know we will lose state but I am not sure how to differentiate for the "low power operation" case

Any part of the system, be that drivers, subsystems or applications, can register themselves using pm_notifier_register() to be able to follow the soc sleep states as they are entered and exited. devicetree nodes can reference these states freely. For convenience, for devices which can only be enabled/disabled as a whole depending on soc sleep states, can use the default zephyr,disabling-states. Devices which are affected in a more granular way, can define their own sets of states as they see fit, like transmit-disabling-states in the case of this specific UART. These are device specific, and the device driver can lock/unlock/monitor these states freely.

[decsny]

@bjarki-andreasen based on your feedback I have completely changed the approach of this PR, so LMK if it is acceptable. You can see that technically I still have the issue of putting the zephyr,disabling-power-states on the uart node since the "disabling" constraints cant be gotten from the parent domain like I was originally trying to do, which I still have the same issue with. But once this SOC and related drivers are switched to only supporting runtime device PM then it will be able to be removed because as you said, the device just wont be disabled if the parent domain isn't suspended if using runtime device PM. So since it is a technical debt which has a clear plan to remove it's okay to keep it like that temporarily, especially since it was already having this property to begin with. If you are okay with these things I am changing in pm subsystem then I will add the testing and doc.

[decsny]

which can replace the current pm_policy_device_power_lock_get() (which we still need to call from power domains anyway).

yes, I think the idea will be that this "pm_policy_device_power_lock_get/put()" should only be called from the generic pm subsys code to prevent suspending/resuming of power domains / devices , and zephyr,disabling-power-states is the thing that specifies the domain-related affects of pm_runtime_get/put aswell?

BTW, is the pm notifier change alright ? I was surprised it did not already report the substate, and I tried to make the change backwards compatible. I think it will be really important to be able to be told what substate we're going into going forward because my idea of the substates is that they will allow a lot of potential configurability of the hardware/device states that we need.

I would not say this is a temporary approach

And also, what I meant by the "temporary approach" , is that, this uart driver is still using zephyr,disabling-power-states list to call pm_policy_device_power_lock_get/put in order to lock out those states if it is doing any transfer, so that it doesn't go into the low power mode either. Eventually that should be switched to calling pm_runtime_* functions instead, but needs the PM domain refactor PR that you created to be merged first. And also need to switch this RW612 SOC to have runtime device PM support in general before then.

[bjarki-andreasen]

which can replace the current pm_policy_device_power_lock_get() (which we still need to call from power domains anyway).

yes, I think the idea will be that this "pm_policy_device_power_lock_get/put()" should only be called from the generic pm subsys code to prevent suspending/resuming of power domains / devices , and zephyr,disabling-power-states is the thing that specifies the domain-related affects of pm_runtime_get/put aswell?

what I'm pointing out is that zephyr,disabling-power-states is "just" a pm_state_constraint_list, so the changes in this PR can be used as a generic way of defining and locking those states as well.

BTW, is the pm notifier change alright ? I was surprised it did not already report the substate, and I tried to make the change backwards compatible. I think it will be really important to be able to be told what substate we're going into going forward because my idea of the substates is that they will allow a lot of potential configurability of the hardware/device states that we need.

Surprised me to, maybe the notifier was added before substates where or something

I would not say this is a temporary approach

And also, what I meant by the "temporary approach" , is that, this uart driver is still using zephyr,disabling-power-states list to call pm_policy_device_power_lock_get/put in order to lock out those states if it is doing any transfer, so that it doesn't go into the low power mode either. Eventually that should be switched to calling pm_runtime_* functions instead, but needs the PM domain refactor PR that you created to be merged first. And also need to switch this RW612 SOC to have runtime device PM support in general before then.

ah, got you

[decsny]

last push addressed review comments, still need to add doc and testing and rebase

[decsny]

rebased & resolve conflicts

[decsny]

@bjarki-andreasen if you are ok with what is there now, then I will add doc and testing

[bjarki-andreasen]

Really nice, I think this is the way to go forward

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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