From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Kevin Hilman <khilman@ti.com>,
Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
markgross@thegnar.org, Jean Pihet <j-pihet@ti.com>,
Simon Horman <horms@verge.net.au>
Subject: [PATCH 0/3] PM / Domains: Fix device stop and domain power off governor functions, take 2
Date: Wed, 25 Apr 2012 19:28:32 +0000 [thread overview]
Message-ID: <201204252128.33016.rjw@sisk.pl> (raw)
In-Reply-To: <201204242349.26288.rjw@sisk.pl>
Hi all,
On Tuesday, April 24, 2012, Rafael J. Wysocki wrote:
> Hi all,
>
> It turns out that the PM domains device stop and domain power off governor
> functions I invented some time ago don't really make sense, because they
> should only decide whether or not the resulting low-power state will be
> too deep and that only depends on latencies. In particular, the time
> when devices have been suspended doesn't really matter here, so the
> results returned by those functions shouldn't depend on it either (as it
> shouldn't depend on any "break even" values that only make sense when we
> know how much time in advance the device is going to be used, but this
> information is not related to the PM QoS latency constraint).
>
> If this functions are fixed (patches [1/3] and [2/3]), then some ugly
> computations can be removed from rpm_suspend() and other places and the
> whole framework can be simplified quite a bit (patch [3/3]).
I noticed a few problems with the patches sent yesterday. Most importantly:
* dev_pm_qos_read_value() should be used rather than its unlocked counterpart.
* All children of the device have to be taken into account, not only those
belonging to generic PM domains.
* default_power_down_ok() should take restore_state_latency_ns into account.
* default_power_down_ok() should not assume that default_stop_ok() will always
be called before it (the domain may choose to use a different device stop
governor function in principle).
* rpm_resume() still should check the devices PM QoS constraint and return
error code if the value is negative (which means never suspend).
Updated patches follow.
Thanks,
Rafael
next prev parent reply other threads:[~2012-04-25 19:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-24 21:49 [PATCH 0/3] PM / Domains: Fix device stop and domain power off governor functions Rafael J. Wysocki
2012-04-24 21:50 ` [PATCH 1/3] PM / Domains: Rework default device stop governor function Rafael J. Wysocki
2012-04-24 21:50 ` [PATCH 2/3] " Rafael J. Wysocki
2012-04-24 21:55 ` Rafael J. Wysocki
2012-04-24 21:51 ` [PATCH 3/3] PM / Runtime: Remove device fields related to suspend time Rafael J. Wysocki
2012-04-25 19:28 ` Rafael J. Wysocki [this message]
2012-04-25 19:29 ` [PATCH 1/3] PM / Domains: Rework default device stop governor function, v2 Rafael J. Wysocki
2012-04-25 19:30 ` [PATCH 2/3] PM / Domains: Rework default domain power off " Rafael J. Wysocki
2012-04-25 19:30 ` [PATCH 3/3] PM / Runtime: Remove device fields related to suspend time, v2 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=201204252128.33016.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=horms@verge.net.au \
--cc=j-pihet@ti.com \
--cc=khilman@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=markgross@thegnar.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).