From: Kevin Hilman <khilman@ti.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Len Brown <lenb@kernel.org>,
Colin Cross <ccross@android.com>,
Magnus Damm <magnus.damm@gmail.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>
Subject: Re: [Update 2x][RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support
Date: Wed, 23 May 2012 15:23:00 -0700 [thread overview]
Message-ID: <87sjeqzge3.fsf@ti.com> (raw)
In-Reply-To: 201205162229.38252.rjw@sisk.pl
Hi Rafael,
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> On some systems there are CPU cores located in the same power
> domains as I/O devices. Then, power can only be removed from the
> domain if all I/O devices in it are not in use and the CPU core
> is idle. Add preliminary support for that to the generic PM domains
> framework.
>
> First, the platform is expected to provide a cpuidle driver with one
> extra state designated for use with the generic PM domains code.
> This state should be initially disabled and its exit_latency value
> should be set to whatever time is needed to bring up the CPU core
> itself after restoring power to it, not including the domain's
> power on latency. Its .enter() callback should point to a procedure
> that will remove power from the domain containing the CPU core at
> the end of the CPU power transition.
>
> The remaining characteristics of the extra cpuidle state, referred to
> as the "domain" cpuidle state below, (e.g. power usage, target
> residency) should be populated in accordance with the properties of
> the hardware.
>
> Next, the platform should execute genpd_attach_cpuidle() on the PM
> domain containing the CPU core. That will cause the generic PM
> domains framework to treat that domain in a special way such that:
>
> * When all devices in the domain have been suspended and it is about
> to be turned off, the states of the devices will be saved, but
> power will not be removed from the domain. Instead, the "domain"
> cpuidle state will be enabled so that power can be removed from
> the domain when the CPU core is idle and the state has been chosen
> as the target by the cpuidle governor.
>
> * When the first I/O device in the domain is resumed and
> __pm_genpd_poweron(() is called for the first time after
> power has been removed from the domain, the "domain" cpuidle
> state will be disabled to avoid subsequent surprise power removals
> via cpuidle.
This looks like a good approach. I like that it keeps a pretty clean
separation between CPUidle and PM domains.
My only comment would be that the recalc of the exit_latency should be
described a bit more. Specifically, I'm not sure why it's adjused at
every genpd poweron. At first I thought it was just supposed to be
adjusted upon attach, then adjusted back on detatch, but with the recalc
also in every poweron, I'm a little confused. Care to clarify?
Thanks,
Kevin
next prev parent reply other threads:[~2012-05-23 22:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 21:40 [RFC][PATCH 0/2] PM / Domains / cpuidle: Preliminary cpuidle support for generic PM domains Rafael J. Wysocki
2012-05-09 21:41 ` [RFC][PATCH 1/2] PM / cpuidle: Add driver reference counter Rafael J. Wysocki
2012-05-09 21:43 ` [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support Rafael J. Wysocki
2012-05-10 10:10 ` Santosh Shilimkar
2012-05-10 18:41 ` Rafael J. Wysocki
2012-05-11 8:23 ` Santosh Shilimkar
2012-05-11 8:35 ` Magnus Damm
2012-05-11 18:59 ` Rafael J. Wysocki
2012-05-12 6:32 ` Shilimkar, Santosh
2012-05-12 19:33 ` Rafael J. Wysocki
2012-05-14 6:14 ` Shilimkar, Santosh
2012-05-12 19:40 ` [Update][RFC][PATCH " Rafael J. Wysocki
2012-05-16 20:29 ` [Update 2x][RFC][PATCH " Rafael J. Wysocki
2012-05-23 22:23 ` Kevin Hilman [this message]
2012-05-24 16:17 ` Rafael J. Wysocki
2012-05-24 23:59 ` Kevin Hilman
2012-05-28 21:50 ` [Update 3x][PATCH 2/2] PM / Domains: Add preliminary support for cpuidle Rafael J. Wysocki
2012-05-30 22:18 ` Kevin Hilman
2012-05-31 19:02 ` Rafael J. Wysocki
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=87sjeqzge3.fsf@ti.com \
--to=khilman@ti.com \
--cc=arjan@linux.intel.com \
--cc=ccross@android.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=rjw@sisk.pl \
--cc=santosh.shilimkar@ti.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