linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jassisinghbrar@gmail.com (jassi brar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] IDLE/DEEP IDLE scheduler modification for power savings
Date: Mon, 12 Apr 2010 21:55:28 +0900	[thread overview]
Message-ID: <s2q1b68c6791004120555qb0ab21ffm9a641ec3f2423597@mail.gmail.com> (raw)
In-Reply-To: <000001cada24$01a5ee90$04f1cbb0$%majewski@samsung.com>

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.

  reply	other threads:[~2010-04-12 12:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-12  9:39 [RFC] IDLE/DEEP IDLE scheduler modification for power savings Lukasz Majewski
2010-04-12 12:55 ` jassi brar [this message]
2010-05-11  0:22   ` Ben Dooks
2010-04-13  8:57 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s2q1b68c6791004120555qb0ab21ffm9a641ec3f2423597@mail.gmail.com \
    --to=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).