search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.85k stars 6.6k forks source link

Power Management Infrastructure #14307

Closed pizi-nordic closed 8 months ago

pizi-nordic commented 5 years ago

This issue tracks all activity intended to improve power management in Zephyr.

Known bugs / missing features:

pizi-nordic commented 5 years ago

FYI: @nashif, @carlescufi

endian-benjamin commented 5 years ago

Any plans to follow this up with a workshop-like meeting or anything like that? I'd be very interested in participating. It seems like everyone has just temporarily given up on PM. Would be nice to reinvigorate the discussion.

mnkp commented 5 years ago

Would be nice to reinvigorate the discussion.

I'm actually also very interested in continuing development of the Power Management Subsystem. Finding enough free time is the only issue.

leapslabs commented 5 years ago

Hi All,

I have found a problem with Power Manager (PM) in Zephyr and have not found an answer. So I tried to study more in details and below are my findings. Please correct me if I am wrong: 1) Basically it's built around the Idle thread which has the lowest priority. 2) When no other higher priority thread is pending then the Idle thread will run. 3) The Idle thread when running will call sys_power_save_idle and based on PM policy (defined by time range) the PM might enter one of the energy saving state. 4) Application can overwrite entry/exit function to implement application dependent actions when the system change states. 5) PM of device drivers/interfaces - the PM offers 2 ways to control the device drivers: a) Centralized - when the suspend is triggered from the Idle thread and resume is triggered from the hardware event. b) Distributed - the User Application triggers the device suspend/resume.

Here I see the problem: 1) The whole concept of triggering the suspend is based around timeouts. I have not found anyway to put the system into sleep without the need to define the future wake up time. 2) There are applications which do not wake up on time event but e.g. on accelerometer, a button, GPIO toggling by a host MCU, etc. As it is currently I have not found a way to put the system into suspend mode without setting future wake up time. I don't want to deep sleep the device since it would put the device in SHUTDOWN mode and a wake up event would trigger device reset. 3) Current timeout concept does not allow to set absolute timeout value with higher resolution than ms/ticks. So I use an extra RTC as a wakeup device. My problem now is I have no way to put the system in suspend mode (with the system context being stored) unless setting some timeout in a very long future. E.g. on nRF52832 RTC that would be max. only 512 s (24-bit counter running at 32kHz). 4) There is k_cpu_idle but it can be used only on single thread system. 5) k_yield cannot be used to suspend the system because it would return immediately if there is no other thread to run.

Could anyone please help me to clarify this?

Thank you!

pabigot commented 4 years ago

@nashif @carlescufi I understand we're to put requirements here, but I don't know what exactly you want done. Editing the description isn't scalable or traceable.

But here's one from slack today:

wentongwu commented 4 years ago
  • The power management solution shall support enabling device power management without enabling system power management.

@pabigot sorry I missed this information on slack, what's the usage case here? If nothing to do, CPU just do useless loop?

pabigot commented 4 years ago
  • The power management solution shall support enabling device power management without enabling system power management.

@pabigot sorry I missed this information on slack, what's the usage case here? If nothing to do, CPU just do useless loop?

The discussion is here and should be available for a couple days.

In this case it's because device power management is needed but the target doesn't support system power management. The dependency is also a bug in the current implementation.

In the general case it's because device power management is needed and the application needs no system-level power management beyond runtime-idle. It should be possible to control device power (either manually or through a policy) without incurring overhead for support of suspend-to-idle or other states in #24228 that are not runtime states. This is a stakeholder expectation from which the requirement derives.

vanti commented 4 years ago

A couple of requirements I can think of:

  1. Driver APIs should be made power-friendly, so that the driver can internally tell the power management infrastructure whether a device is needed or not at runtime. One example is #23798, where the UART's poll-based APIs expect the UART to be on outside the scope of the functions. Given the UART driver does not have open/close APIs either, there isn't a way for the driver to tell when the UART can be turned off.

  2. Support of power domains. On some SoCs such as the TI CC1352, devices are grouped into domains that are power-gated together as a set. There can also be dependencies between domains (one domain may need to be turned on in order for another to be on). The power management infrastructure should provide a way to specify these dependencies (possibly via DT), and runtime device power management should be able to leverage them to automatically turn off unused domains and turn them back on when needed.

wentongwu commented 4 years ago

one requirement as https://github.com/zephyrproject-rtos/zephyr/issues/24230 stated, the framework shouldn't assume the device state transition happens only with irq locked, some devices need interrupt involved to do state sync.

wentongwu commented 4 years ago

In the general case it's because device power management is needed and the application needs no system-level power management beyond runtime-idle. It should be possible to control device power (either manually or through a policy) without incurring overhead for support of suspend-to-idle or other states in #24228 that are not runtime states. This is a stakeholder expectation from which the requirement derives.

Thanks, but it doesn't beyond the scope defined by #24228 where system-level pm will take care runtime-idle and device runtime pm(https://github.com/zephyrproject-rtos/zephyr/pull/26366) will control device power with claim/release.

pabigot commented 4 years ago

That doesn't make sense: You've specified a solution which doesn't satisfy my requirement. What we have today in Zephyr allows runtime idle (WFI when the system idle thread is the only activity) without enabling system power management. That configuration should continue to be supported.

pabigot commented 4 years ago

I'm not going to try to do system engineering on the whole power management infrastructure, but I decided to give a shot to clarifying the dependencies associated with device power management. A first draft is available here, starting with three specific use cases and proceeding to a set of derived requirements.

The draft hints at a solution to supporting multiple power states as individual resources, which decouples the API from any need to express transitions other than to an ON state (signaled by introducing a constraint). The transition out of ON (release of a constraint) goes to another state identified by remaining active dependencies. This seems to be a fairly powerful and simple model, but it's not compatible with #26366. It's not clear how to handle the use cases I've identified with #26366.

In any case it's there for discussion, and I'm going back to the technical concerns of associating resource handles with devices and non-device elements.

pabigot commented 4 years ago

This was mentioned last week but I don't see it recorded anywhere, so:

This covers an expectation from Nordic that an application have complete control of what power transitions occur at any time.

As written this is intended to cover suspend (system) and device power states. There's a subtlety related to runtime that could be explored.

pabigot commented 4 years ago

13382 was merged with very weak support. The concerns raised in that PR should probably inform the planning of new power management capabilities.

wentongwu commented 4 years ago 
  o Power Domain - Electronic circuit that is supplied its input power by the
                   output power of a regulator, switch or by another power
                   domain.

                   The supply regulator may be behind a switch(s). i.e.

                   Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
                              |             |
                              |             +-> [Consumer B], [Consumer C]
                              |
                              +-> [Consumer D], [Consumer E]

                   That is one regulator and three power domains:

                   Domain 1: Switch-1, Consumers D & E.
                   Domain 2: Switch-2, Consumers B & C.
                   Domain 3: Consumer A.

                   and this represents a "supplies" relationship:

                   Domain-1 --> Domain-2 --> Domain-3.

                   A power domain may have regulators that are supplied power
                   by other regulators. i.e.

                   Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
                                |
                                +-> [Consumer B]

                   This gives us two regulators and two power domains:

                   Domain 1: Regulator-2, Consumer B.
                   Domain 2: Consumer A.

                   and a "supplies" relationship:

                   Domain-1 --> Domain-2

a power domain definition from https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

nashif commented 8 months ago

closing as complete.