From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kevin Hilman <khilman@ti.com>
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: Thu, 24 May 2012 18:17:43 +0200 [thread overview]
Message-ID: <201205241817.43541.rjw@sisk.pl> (raw)
In-Reply-To: <87sjeqzge3.fsf@ti.com>
On Thursday, May 24, 2012, Kevin Hilman wrote:
> 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?
The problem is that the PM domains code measures the time it takes to
power off a domain and updates its power on latency parameter if the
measured time is greater. This is done for PM QoS to operate on realistic
numbers (most of the time at least).
Of course, this also affects the CPU wakeup latency if the wakeup involves
turning a domain on.
Thanks,
Rafael
next prev parent reply other threads:[~2012-05-24 16:12 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
2012-05-24 16:17 ` Rafael J. Wysocki [this message]
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=201205241817.43541.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arjan@linux.intel.com \
--cc=ccross@android.com \
--cc=khilman@ti.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--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