Date
1 - 3 of 3
RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
Areas to be implemented next:
1. ARC deep sleep support:
- Currently ARC in quark_se would be reset upon deep sleep initiated
from x86 core. It needs something like _sys_soc_resume() called at boot
time so it can restore states and resume at the point it suspended.
Suspend would be invoked from the x86 side so there is no need for a
suspend function.
2. Nanokernel tickless idle PM support:
- Currently tickless idle PM hooks are called only in microkernel idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of functions
uniform.
3. The naming of CONFIG flags and functions:
- The CONFIG flag names would be made consistent with the new power
management implementation. Also the dependencies between the flags
would be improved and unnecessary fags removed.
Feedbacks/Suggestions:
1. Provide arch specific helper functions used in the PM service app to
do state transitions and save/restore CPU thread contexts.
- Zephyr has arch specific code in arch folders. The suggestion is to
add functions in these locations and abstract them to the PM service app.
1. ARC deep sleep support:
- Currently ARC in quark_se would be reset upon deep sleep initiated
from x86 core. It needs something like _sys_soc_resume() called at boot
time so it can restore states and resume at the point it suspended.
Suspend would be invoked from the x86 side so there is no need for a
suspend function.
2. Nanokernel tickless idle PM support:
- Currently tickless idle PM hooks are called only in microkernel idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of functions
uniform.
3. The naming of CONFIG flags and functions:
- The CONFIG flag names would be made consistent with the new power
management implementation. Also the dependencies between the flags
would be improved and unnecessary fags removed.
Feedbacks/Suggestions:
1. Provide arch specific helper functions used in the PM service app to
do state transitions and save/restore CPU thread contexts.
- Zephyr has arch specific code in arch folders. The suggestion is to
add functions in these locations and abstract them to the PM service app.
Boie, Andrew P
On Mon, 2016-02-29 at 10:00 +0000, Thomas, Ramesh wrote:
Tickless idle and PM are orthogonal!
Tickless idle means we don't come out of idle to just serve periodic
timer interrupts, we come out of idle for the next scheduled event or
an IRQ. You don't need "PM Hooks" for tickless idle...
Andrew
2. Nanokernel tickless idle PM support:With all due respect what are you talking about?
- Currently tickless idle PM hooks are called only in microkernel
idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of
functions
uniform.
Tickless idle and PM are orthogonal!
Tickless idle means we don't come out of idle to just serve periodic
timer interrupts, we come out of idle for the next scheduled event or
an IRQ. You don't need "PM Hooks" for tickless idle...
Andrew
Thomas, Ramesh
On Tue, 2016-03-01 at 21:23 +0000, Boie, Andrew P wrote:
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 the kernel.
This is a very efficient way to save power and probably going to be the
most used feature. The system is going to be idle for varied amounts of
time as determined by the tickless idle logic. Kernel notifies PM
service before it goes to idle and when it exits idle. Depending upon
the idle time available, peripherals and clocks can be turned off saving
additional power. In some SoCs that do not support deep sleep, this is
the only way to do power management.
Based on feedbacks to earlier RFCs this interface is combined with the
SoC power management i.e. deep sleep interface. It is better combined
because now the PM App service can make decisions at one place. It can
just turn off clocks and peripherals and let the kernel do its idle if
the time is short. If the system is going to be idle for prolonged
periods, then it can decide to go to deep sleep. The decisions are
based on wake latencies of each operation and the power policies that
the PM service app implements.
On Mon, 2016-02-29 at 10:00 +0000, Thomas, Ramesh wrote:This is to give an opportunity for the PM service app to do additional2. Nanokernel tickless idle PM support:With all due respect what are you talking about?
- Currently tickless idle PM hooks are called only in microkernel
idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of
functions
uniform.
Tickless idle and PM are orthogonal!
Tickless idle means we don't come out of idle to just serve periodic
timer interrupts, we come out of idle for the next scheduled event or
an IRQ. You don't need "PM Hooks" for tickless idle...
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 the kernel.
This is a very efficient way to save power and probably going to be the
most used feature. The system is going to be idle for varied amounts of
time as determined by the tickless idle logic. Kernel notifies PM
service before it goes to idle and when it exits idle. Depending upon
the idle time available, peripherals and clocks can be turned off saving
additional power. In some SoCs that do not support deep sleep, this is
the only way to do power management.
Based on feedbacks to earlier RFCs this interface is combined with the
SoC power management i.e. deep sleep interface. It is better combined
because now the PM App service can make decisions at one place. It can
just turn off clocks and peripherals and let the kernel do its idle if
the time is short. If the system is going to be idle for prolonged
periods, then it can decide to go to deep sleep. The decisions are
based on wake latencies of each operation and the power policies that
the PM service app implements.
Andrew