[RFC] IDLE/DEEP IDLE scheduler modification for power savings
jassi brar
jassisinghbrar at gmail.com
Mon Apr 12 08:55:28 EDT 2010
On Mon, Apr 12, 2010 at 6:39 PM, Lukasz Majewski <l.majewski at 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.
More information about the linux-arm-kernel
mailing list