[RFC] IDLE/DEEP IDLE scheduler modification for power savings

[RFC] IDLE/DEEP IDLE scheduler modification for power savings

[Lukasz Majewski]

Hello all,

I'd like to ask for comments and possible ways of solution for the following
problem:

Some SoCs allow for entering IDLE mode when they know that the system will
be
"inactive" for some time (to be more precise it will execute the idle task -
which prepares system to enter IDLE state). In that mode CPU core is not
active
(CPU core is clock gated) and may be woken up by several interrupts. IDLE
mode entering is already implemented in the kernel and works smoothly.

It is also possible in some SoCs to go even further and use the DEEP IDLE
mode, which (like in the case of Samsung) allows for power gating for
several
internal blocks (including CPU). In this state chip PLLs are disabled and
several hundreds of microseconds are needed to restore the processor state
after waking up. The benefit of this mode is that the power consumption of
the system can be significantly reduced. One of the possible use cases of
this mode is the Low Power Audio Player in conjunction with ALSA and
kernel's
CPU idle framework. However the waking up from this state may be performed
with use of smaller number of the wake up sources when compared to ordinary
IDLE state (because of power gating of SoC internal blocks).

One approach to solve the problem, and therefore deliver power savings,
is to modify the ALSA driver and provide a switch to inform the CPU IDLE
framework that it should now use the DEEP IDLE instead of IDLE when entering
the Low Power Audio playback mode is expected.  This change may be performed
by replacing the method for entering the IDLE mode to DEEP IDLE. Moreover
some sources immune to power gating (like e.g. RTC timer) have to be used
for waking up. The biggest problem for this approach is the kernel's policy
violation, that no user program should directly change scheduling/idle
policy.

In my humble opinion, maybe a better solution would be to add a new
scheduling
policy or modify the CFS scheduler to evaluate if the time for next task
execution is bigger than the time needed to wake up (and restore the system 
state) from DEEP IDLE (in my case it is more than several hundred
microseconds).
This approach would allow for using existing CFS scheduler framework (as it
is 
done  with implementation of CFS, or Real-Time policies) and prevent from
threads 
mentioned above (i.e. changing the CPU Idle framework with some "external" 
switch). One more advantage is that the DEEP IDLE mode could be used not
only 
in the above use case (after properly prepared for DEEP IDLE drivers, but
this 
is another issue). This can bring extra power savings for battery operated 
systems.

So what is your opinion about integrating use of the DEEP IDLE state mode
in the scheduler (either as new scheduling policy or modifying scheduler
code)?

Any comments will be appreciated.

Best regards,

Lukasz Majewski
Samsung Poland R&D Center
Platform Group

[RFC] IDLE/DEEP IDLE scheduler modification for power savings

[jassi brar]

On Mon, Apr 12, 2010 at 6:39 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> One approach to solve the problem, and therefore deliver power savings,
> is to modify the ALSA driver and provide a switch to inform the CPU IDLE
> framework that it should now use the DEEP IDLE instead of IDLE when entering
> the Low Power Audio playback mode is expected. ?This change may be performed
> by replacing the method for entering the IDLE mode to DEEP IDLE. Moreover
> some sources immune to power gating (like e.g. RTC timer) have to be used
> for waking up. The biggest problem for this approach is the kernel's policy
> violation, that no user program should directly change scheduling/idle
> policy.
Actually any power saving mode is transparent to the LPAM(LowPowerAudioMode).
"LPAM h/w" is simply an I2S controller with an additional 'overlay'
stereo channel
which is h/w-mix'ed with the first two of the 6 channels. And these overlay
channels works just as well in normal power mode. LPAM is but one
ramification of
of the platform using the interrupt as a wakeup source. It is also used for
low latency playback like 'alerts' and 'alarms'.
Our LPAM doesn't work right away not because of the power management stack
but because ASoC can't yet handle a
codec-active-in-system-suspended-mode scenario.
So, I too think it's a bad idea to hack core PM for things like LPAM.

> So what is your opinion about integrating use of the DEEP IDLE state mode
> in the scheduler (either as new scheduling policy or modifying scheduler
> code)?
imho, such 'variation' in suspend had better be implemented in
platform specific manner.
Just because samsung's manual call it deep-IDLE doesn't make it an 'IDLE' mode.
It is closer to suspend than idle, at least to me.

[RFC] IDLE/DEEP IDLE scheduler modification for power savings

[Mark Brown]

On Mon, Apr 12, 2010 at 11:39:05AM +0200, Lukasz Majewski wrote:

> Some SoCs allow for entering IDLE mode when they know that the system will
> be
> "inactive" for some time (to be more precise it will execute the idle task -
> which prepares system to enter IDLE state). In that mode CPU core is not
> active
> (CPU core is clock gated) and may be woken up by several interrupts. IDLE
> mode entering is already implemented in the kernel and works smoothly.

Have you looked at the cpuidle infrastructure in the kernel?  It's
mostly used on desktop systems at the minute but IIRC there was some
investigation into use in embedded environments.  There's also the work
that's been done on OMAP and SH CPUs in this area.

[RFC] IDLE/DEEP IDLE scheduler modification for power savings

[Ben Dooks]

On Mon, Apr 12, 2010 at 09:55:28PM +0900, jassi brar wrote:
> On Mon, Apr 12, 2010 at 6:39 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > One approach to solve the problem, and therefore deliver power savings,
> > is to modify the ALSA driver and provide a switch to inform the CPU IDLE
> > framework that it should now use the DEEP IDLE instead of IDLE when entering
> > the Low Power Audio playback mode is expected. ?This change may be performed
> > by replacing the method for entering the IDLE mode to DEEP IDLE. Moreover
> > some sources immune to power gating (like e.g. RTC timer) have to be used
> > for waking up. The biggest problem for this approach is the kernel's policy
> > violation, that no user program should directly change scheduling/idle
> > policy.
> Actually any power saving mode is transparent to the LPAM(LowPowerAudioMode).
> "LPAM h/w" is simply an I2S controller with an additional 'overlay'
> stereo channel
> which is h/w-mix'ed with the first two of the 6 channels. And these overlay
> channels works just as well in normal power mode. LPAM is but one
> ramification of
> of the platform using the interrupt as a wakeup source. It is also used for
> low latency playback like 'alerts' and 'alarms'.
> Our LPAM doesn't work right away not because of the power management stack
> but because ASoC can't yet handle a
> codec-active-in-system-suspended-mode scenario.
> So, I too think it's a bad idea to hack core PM for things like LPAM.
> 
> > So what is your opinion about integrating use of the DEEP IDLE state mode
> > in the scheduler (either as new scheduling policy or modifying scheduler
> > code)?
> imho, such 'variation' in suspend had better be implemented in
> platform specific manner.
> Just because samsung's manual call it deep-IDLE doesn't make it an 'IDLE' mode.
> It is closer to suspend than idle, at least to me.

It does seem to be a form of suspend, as it halts the SDRAM and powers
down the ARM core... this means that there's a whole pile of stuff that
needs to be considered before allowing the system to go into such a state.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.