That is good. (Note - since RFC will be readily accessible now, question of how much it should stay in sync with deviations during actual implementation/review would be a question to answer later.) Wh

I see. So the method in the RFC is to assist in diagnosis or notification of critical errors.

Not sure how the method in the RFC differentiates between critical and non-critical errors. Isn't the driver also *not* passing on the non-critical error status to the app by not setting device_api =

Problem Statement: -------------------------- Entering deep sleep states during pending device transactions can cause transaction inconsistencies. Why this is a problem: -----------------------------

[Rev 1.2 - Added a parameter to .suspend() and .resume() functions indicating the power policy used by the PMA. This parameter will help driver take policy based optimized actions. Described in detail

(Revised and incorporated feedbacks. The term "Tickless Idle" was found confusing to be used to refer to a PM policy. That is a specific term used for an optimized kernel idling mechanism saving power

[Revised incorporating feedbacks. The changes are shown at the end] Problem Statement: Not all Zephyr kernel drivers provide the same interfaces. Why this is a problem: ----------------------------- T

[Revised incorporating feedbacks so far] Problem Statement: Power management Kconfig flags are not consistent and hierarchy is not clear Why this is a problem: ----------------------------- The names

Sounds good. We can use the SYS_INIT_NAMED() macro for devices that need a name for PM purpose. Do you think we should replace SYS_INIT() with the new one? i.e. just modify SYS_INIT(). I am ok either

The list enables the PMA to choose the order in which it suspends/resumes the devices by creating its own ordered list based on policies. If the iteration is done by the kernel then the order will be

The power manager application should be able to handle that case. It can either retry after trying other drivers, ignore that driver or abort suspend. The callback is not going to help because _sys_so

Problem Statement: Add OS infrastructure to enable application-based power management policies, which is architecture independent, supports microkernel and nanokernel and the interface clearly identif

Problem Statement: Zephyr needs to provide an architecture independent method for power management application to invoke the SOC Deep Sleep functionality. Why this is a problem: ----------------------

Problem Statement: Zephyr needs to provide an architecture independent method for power management application to invoke a low power state on the CPU. Why this is a problem: --------------------------

Problem Statement: Not all Zephyr kernel drivers provide the same interfaces. Why this is a problem: ----------------------------- The Zephyr kernel currently has devices that are essential for core O

Problem Statement: Power management Kconfig flags are not consistent and hierarchy is not clear Why this is a problem: ----------------------------- The names include terms like “ADVANCED” which are n

Here are the revised RFCs that attempts to state the problems, reasons and solutions more clearly Thanks to Dan for spending a lot of time with me in making it right. (It was a challenge to put things

Sure. I will be glad to work with you on making it better. Thanks.

device called In this RFC I tried to keep the main ideas and feedbacks from the original RFCs but made some modifications as I encountered issues during implementation. These should not impact the gen

This is to give an opportunity for the PM service app to do additional operations saving power around the tickless idle i.e. do more than just rely on the power savings achieved by HLT that is done by