All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: jassi brar <jassisinghbrar@gmail.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Tomasz Fujak <t.fujak@samsung.local>,
	Marek Szyprowski <m.szyprowski@samsung.local>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [RFC] IDLE/DEEP IDLE scheduler modification for power savings
Date: Tue, 11 May 2010 01:22:13 +0100	[thread overview]
Message-ID: <20100511002212.GA26401@trinity.fluff.org> (raw)
In-Reply-To: <s2q1b68c6791004120555qb0ab21ffm9a641ec3f2423597@mail.gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] IDLE/DEEP IDLE scheduler modification for power savings
Date: Tue, 11 May 2010 01:22:13 +0100	[thread overview]
Message-ID: <20100511002212.GA26401@trinity.fluff.org> (raw)
In-Reply-To: <s2q1b68c6791004120555qb0ab21ffm9a641ec3f2423597@mail.gmail.com>

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.

  reply	other threads:[~2010-05-11  0:22 UTC|newest]

Thread overview: 8+ 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  9:39 ` Lukasz Majewski
2010-04-12 12:55 ` jassi brar
2010-04-12 12:55   ` jassi brar
2010-05-11  0:22   ` Ben Dooks [this message]
2010-05-11  0:22     ` Ben Dooks
2010-04-13  8:57 ` Mark Brown
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=20100511002212.GA26401@trinity.fluff.org \
    --to=ben-linux@fluff.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=kyungmin.park@samsung.com \
    --cc=l.majewski@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.local \
    --cc=mingo@redhat.com \
    --cc=t.fujak@samsung.local \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.