Zephyr power management enhancement plan

[bjarki-andreasen]

Introduction

This issue documents and tracks the changes needed to refactor PM device to achieve what is proposed in #84049.

High level steps

1. Use power domains/devices to dictate system state constraints instead of system state controling power domains/devices PM_DEVICE_POWER_DOMAIN refactor #89372

2. Replace uses of PM_DEVICE_SYSTEM_MANAGED with PM_DEVICE_RUNTIME in all applications.

3. Remove PM_DEVICE_SYSTEM_MANAGED. The system state will not be used to manage devices, this option therefore has no utility, and shall be removed.

4. Remove pm_device_runtime_enable() and the zephyr,pm-device-runtime-auto devicetree property. All devices will be managed by PM_DEVICE_RUNTIME if enabled, disabling it per device is not a valid pm device configuration.

5. Clean up all device drivers. This includes the following:

   • Use pm_device_driver_init() instead of calling pm_device_runtime_enable(), pm_device_init_suspended() etc.
   • Use pm_device_runtime_ APIs for resuming device dependencies like busses, pwms, etc, from device drivers.

   note: we will not remove inline calls to self get/put in can_start() or i2c_transfer() at this time.

6. Adjust subsystems and applications (samples) which currently use pm_device_action_run to solely use pm_device_runtime APIs.

7. Remove inline self get/put calls from device drivers, like often present in can_start()/can_stop() or i2c_transfer(). These are no longer needed as applications/subsystems are mandated to call these APIs before and after using the device.

[ceolin]

@bjarki-andreasen thanks for creating it. From my understanding it is missing creating power domains for internal devices, otherwise those devices won't never know when they are powered off. Other than that is looking great.

[bjarki-andreasen]

@bjarki-andreasen thanks for creating it. From my understanding it is missing creating power domains for internal devices, otherwise those devices won't never know when they are powered off. Other than that is looking great.

Right! that is step actually step 1 :)

[ceolin]

@bjarki-andreasen thanks for creating it. From my understanding it is missing creating power domains for internal devices, otherwise those devices won't never know when they are powered off. Other than that is looking great.

Right! that is step actually step 1 :)

Ah cool, I thought it was just referring to current ones.

[nashif]

7. Remove inline self get/put calls from device drivers, like often present in can_start()/can_stop() or i2c_transfer(). These are no longer needed as applications/subsystems are mandated to call these APIs before and after using the device.

I am not following this change, this is a pillar and a fundemntal deisgn of runtime device power management. Need more information and details about this change and what does it fix/provide.

I think I understand some of the other items, but there need to be some more details and probably we need an overview of the overall power management architecture, why those changes are needed and where we will end up and if anything else is going to follow or if those changes get us where want to be.

[bjarki-andreasen]

7. Remove inline self get/put calls from device drivers, like often present in can_start()/can_stop() or i2c_transfer(). These are no longer needed as applications/subsystems are mandated to call these APIs before and after using the device.

I am not following this change, this is a pillar and a fundemntal deisgn of runtime device power management. Need more information and details about this change and what does it fix/provide.

I think I understand some of the other items, but there need to be some more details and probably we need an overview of the overall power management architecture, why those changes are needed and where we will end up and if anything else is going to follow or if those changes get us where want to be.

See the parent issue #84049 for details. This issue just describes the how, not the why :)

[decsny]

Would the busy status indication have any use or be removed along with system managed device PM ?

[decsny]

@bjarki-andreasen thanks for creating it. From my understanding it is missing creating power domains for internal devices, otherwise those devices won't never know when they are powered off. Other than that is looking great.

Right! that is step actually step 1 :)

do you think it would it be feasible to have a generic driver or at least some common code for the concept of an "internal SOC domain"?

BTW, I am new to the power management area of zephyr, but I noticed NXP has this type of thing in a platform DT:

zephyr/dts/arm/nxp/nxp_rw6xx_common.dtsi

Lines 86 to 90 in 96f51bf

	power_mode3_domain: power_mode3_domain {
	compatible = "power-domain-soc-state-change";
	onoff-power-states = <&standby>;
	#power-domain-cells = <0>;
	};

with this binding and this implementation. It seems like it's a power domain representing an SOC system power mode/state instead of a power region in the SOC. Is this wrong / does it need to be changed ? Because on this platform for example there are different domains in the SOC and they are affected differently by the different power states, so having a power domain driver for a power mode seems backwards.

Is there some other mechanism to indicate to devices that the power domain will be turned on or off from a system power mode transition, or is it supposed to be the other way around with something like where devices indicate to domains that they are busy and domains block the system power mode transition?

[bjarki-andreasen]

Would the busy status indication have any use or be removed along with system managed device PM ?

Given device states now dictate what system states can be entered, the busy flag is not needed. The system simply can't change into a state which would conflict with the state of the device :)

[bjarki-andreasen]

@bjarki-andreasen thanks for creating it. From my understanding it is missing creating power domains for internal devices, otherwise those devices won't never know when they are powered off. Other than that is looking great.

Right! that is step actually step 1 :)

do you think it would it be feasible to have a generic driver or at least some common code for the concept of an "internal SOC domain"?

That is what I'm working towards with step 1. In short, an "internal SOC domain" is simply a power domain which constrains system states, like any device can today :)

soc_pd: soc-pd {
        compatible = "power-domain";
        zephyr,disabling-power-states = <&soc_sleep, &soc_deep_sleep>;
};

my-dev {
        compatible = "my-dev";
        power-domains = <&soc_pd>;
};

The driver for "power-domain" would just be an "empty" device which defines a PM_DEVICE. I'm moving all logic required for power domains up to PM_DEVICE_RUNTIME, so power domain drivers just have to implement PM_DEVICE_ACTION_SUSPEND and PM_DEVICE_ACTION_RESUM. Calling power domain children will be done automatically :)

BTW, I am new to the power management area of zephyr, but I noticed NXP has this type of thing in a platform DT:

zephyr/dts/arm/nxp/nxp_rw6xx_common.dtsi

Lines 86 to 90 in 96f51bf

power_mode3_domain: power_mode3_domain {
compatible = "power-domain-soc-state-change";
onoff-power-states = <&standby>;
#power-domain-cells = <0>;
};

with this binding and this implementation. It seems like it's a power domain representing an SOC system power mode/state instead of a power region in the SOC. Is this wrong / does it need to be changed ? Because on this platform for example there are different domains in the SOC and they are affected differently by the different power states, so having a power domain driver for a power mode seems backwards.
Is there some other mechanism to indicate to devices that the power domain will be turned on or off from a system power mode transition, or is it supposed to be the other way around with something like where devices indicate to domains that they are busy and domains block the system power mode transition?

Exactly this: "is it supposed to be the other way around with something like where devices indicate to domains that they are busy and domains block the system power mode transition?"

users call pm_device_runtime_get() on what they need, say an I2C controller, PM_DEVICE_RUNTIME checks if the controller is on one or more power domains, it then resumes the power domains, some of which may prevent specific sleep states from being transitioned to, then resumes the I2C controller itself :)

[bjarki-andreasen]

@decsny Here's the "internal SOC"/default power domain after the refactor 646281a

Its empty, given all power domain and pm policy constraints are part of PM_DEVICE_RUNTIME :)