Re: [RFC] Power Management Infrastructure

Thomas, Ramesh

On 07/14/2016 01:36 AM, D'alton, Alexandre wrote:

Please find comments below.


-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)]
Sent: Thursday, July 14, 2016 9:32 AM
To: devel(a)
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is
not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the
device policies.

That made me think why we originally came up with 2 functions when one was
enough. Probably we thought the same way - to keep symmetry. Problem is that
we will keep getting more needs and we will either add more functions to
device_pm_ops or will have to change existing ones.

Because, we agreed on the fact that suspend resume were managed by a central entity and was the only needed control over the drivers. I think this is still true.
That does not explain why 2 functions are better than 1. In the
scenario you mention, all that is needed is a way to notify the device
of a power state transition.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with
When idle comes the PM service is called and see that it can close the SPI and
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
In my opinion the clock tree needs to be managed completely separately, and in a completely independent way of the pm state.
Each driver mark that they use their clock when active and mark that they do not need it when not active. One can consider that an enabled clock gate is equivalent to a deep sleep forbidden, but that won't be true always on clock gates.

Will the PM service also put devices to suspend state, or only the apps will do it?
Looks like the PM Service will never enter Deep Sleep if any device is on - any

In the above example, the system had to go to idle for the PLL to get turned off.
If you had a central scheme to turn off clocks then the PLL could have been
turned off when both i2c and spi got turned off. Just an observation.

Join to automatically receive all group messages.