From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Paul Walmsley <paul@pwsan.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
Tony Lindgren <tony@atomide.com>,
Arve Hj?nnev?g <arve@android.com>,
Alan Stern <stern@rowland.harvard.edu>,
linux-pm@lists.linux-foundation.org, linux-omap@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>,
Kevin Hilman <khilman@ti.com>, Len Brown <lenb@kernel.org>
Subject: Re: [linux-pm] Runtime PM discussion notes
Date: Wed, 13 Jul 2011 11:04:06 +0200 [thread overview]
Message-ID: <201107131104.06995.rjw@sisk.pl> (raw)
In-Reply-To: <alpine.DEB.2.00.1107130105530.30229@utopia.booyaka.com>
On Wednesday, July 13, 2011, Paul Walmsley wrote:
> (cc'ing Len)
>
> Hi Mark,
>
> On Mon, 11 Jul 2011, Mark Brown wrote:
>
> > The interesting bits are things like being able to kill lots of the SoC
> > core supplies when the RAM is in retention mode - the CPU needs to go
> > through its shutdown procedures.
>
> This is indeed possible on OMAP3+ chips with TWL4030+ PMICs. Probably
> other PMICs also. TI calls it "off-mode." The N900 shipped with this
> feature enabled. Not sure how many other similar products did.
>
> This can be enabled in mainline, but not all of the mainline drivers have
> context save/restore code merged yet, so in mainline it only works with a
> subset of drivers.
>
> > Actually, it just occurred to me that if we're waiting for a system
> > timer and can hand that off to a suitable timer in the PMIC then we can
> > do a suspend to RAM for the deep idle state from the hardware point of
> > view.
>
> Yep. At LinuxCon Cambridge two years ago, we had a discussion about
> whether it would be possible to enter ACPI S-states from CPUIdle (or some
> idle governor) on Intel chips. If I remember correctly, the conclusion
> was that ACPI always disables the screen/backlight, so it would only be
> useful for situations where that was acceptable.
The reason why you can't enter ACPI S-states from CPUidle is because you
need to go out of the idle loop to execute some ACPI-specific stuff. Which
is not even specific to Intel chips, but to ACPI in general.
So entering ACPI S-states from idle is a no-no and I don't think it'll
change in foreseeable future.
> To the best of my (limited) knowledge, that's the only case I know of
> where there's a hardware limitation that prevents dynamic idle from
> reaching the same low power state as system suspend. If someone has hard
> details of a similar example, it would be great to know about it.
Google G1 had this problem IIRC, but I don't have any details.
Thanks,
Rafael
next prev parent reply other threads:[~2011-07-13 9:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BANLkTim=aunvBDLincgXX5yYNhvDTk+fhQ@mail.gmail.com>
[not found] ` <201106102015.47146.rjw@sisk.pl>
[not found] ` <BANLkTimgiJGKASGx80=hTBPBQ52ttmp+Kw@mail.gmail.com>
[not found] ` <201106150048.43187.rjw@sisk.pl>
2011-06-23 14:51 ` Runtime PM discussion notes Paul Walmsley
2011-06-23 15:23 ` [linux-pm] " Alan Stern
2011-06-23 20:34 ` Rafael J. Wysocki
2011-06-24 19:53 ` Paul Walmsley
2011-06-24 22:27 ` Arve Hjønnevåg
2011-06-25 5:33 ` Magnus Damm
2011-06-28 19:47 ` Paul Walmsley
2011-07-09 4:06 ` Mark Brown
2011-07-11 9:58 ` Tony Lindgren
2011-07-11 11:04 ` Mark Brown
2011-07-11 11:14 ` Tony Lindgren
2011-07-11 11:26 ` Mark Brown
2011-07-11 11:32 ` Tony Lindgren
2011-07-13 7:17 ` Paul Walmsley
2011-07-13 9:04 ` Rafael J. Wysocki [this message]
2011-07-29 13:41 ` Pavel Machek
2011-07-29 19:52 ` Rafael J. Wysocki
2011-07-30 20:37 ` Pavel Machek
2011-07-30 21:05 ` Rafael J. Wysocki
2011-07-30 21:09 ` Rafael J. Wysocki
2011-07-30 21:25 ` [linux-pm] " Pavel Machek
2011-07-30 21:36 ` Rafael J. Wysocki
2011-07-30 22:09 ` Pavel Machek
2011-07-30 22:41 ` Rafael J. Wysocki
2011-06-25 13:51 ` [linux-pm] " Rafael J. Wysocki
2011-06-24 18:36 ` Paul Walmsley
2011-06-25 18:59 ` Alan Stern
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=201107131104.06995.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arve@android.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=khilman@ti.com \
--cc=lenb@kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=magnus.damm@gmail.com \
--cc=paul@pwsan.com \
--cc=stern@rowland.harvard.edu \
--cc=tony@atomide.com \
/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