From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: dirk.brandewie@gmail.com
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
rjw@rjwysocki.net, patrick.marlier@gmail.com,
viresh.kumar@linaro.org,
Dirk Brandewie <dirk.j.brandewie@intel.com>
Subject: Re: [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface.
Date: Wed, 19 Mar 2014 00:38:34 +0530 [thread overview]
Message-ID: <532899B2.2060106@linux.vnet.ibm.com> (raw)
In-Reply-To: <1395163361-26380-1-git-send-email-dirk.j.brandewie@intel.com>
On 03/18/2014 10:52 PM, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
>
I don't mean to nitpick, but generally its easier to deal with
patchsets if you post the subsequent versions in fresh email threads.
Otherwise it can get a bit muddled along with too many other email
discussions in the same thread :-(
> Changes:
> v2->v3
> Changed the calling of the ->stop() callback to be conditional on the
> core being the last core controlled by a given policy.
>
Wait, why? I'm sorry if I am not catching up with the discussions on
this issue quickly enough, but I don't see why we should make it
conditional on _that_. I thought we agreed that we should make it
conditional in the sense that ->stop() should be invoked only for
->setpolicy drivers, right?
The way I look at it, ->stop() gives you a chance to stop managing
the CPU going offline. As in "stop this CPU". ->exit() is your chance
to cleanup the policy, since all its users have gone offline (or this
is the last CPU belonging to that policy which is going offline).
With this in mind, we should invoke ->stop() every time we take a
CPU offline, and invoke ->exit() only when the last CPU in the policy
goes offline.
What am I missing?
Regards,
Srivatsa S. Bhat
> v1->2
> Change name of callback function added to cpufreq_driver interface.
>
> Some drivers (intel_pstate) need to modify state on a core before it
> is completely offline. The ->exit() callback is executed during the
> CPU_POST_DEAD phase of the cpu offline process which is too late to
> change the state of the core.
>
> Patch 1 adds an optional callback function to the cpufreq_driver
> interface which is called by the core during the CPU_DOWN_PREPARE
> phase of cpu offline in __cpufreq_remove_dev_prepare().
>
> Patch 2 changes intel_pstate to use the ->stop callback to do
> its cleanup during cpu offline.
>
> Dirk Brandewie (2):
> cpufreq: Add exit_prepare callback to cpufreq_driver interface
> intel_pstate: Set core to min P state during core offline
>
> Documentation/cpu-freq/cpu-drivers.txt | 8 +++++++-
> drivers/cpufreq/cpufreq.c | 3 +++
> drivers/cpufreq/intel_pstate.c | 20 +++++++++++++-------
> include/linux/cpufreq.h | 1 +
> 4 files changed, 24 insertions(+), 8 deletions(-)
>
next prev parent reply other threads:[~2014-03-18 19:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAKQMxzQhVz0QT6tV0PKFjXXpYpDbtnOBH=miARoeQhrvs2TKFQ@mail.gmail.com>
[not found] ` <5320D05F.7050304@gmail.com>
[not found] ` <5320D12B.4040303@gmail.com>
2014-03-13 0:07 ` intel_pstate: Lower p-state when putting down CPU Rafael J. Wysocki
2014-03-13 4:56 ` Viresh Kumar
2014-03-13 21:39 ` Rafael J. Wysocki
2014-03-14 21:03 ` [PATCH v2 0/2] Add exit_prepare callback to the cpufreq_driver interface dirk.brandewie
2014-03-14 21:03 ` [PATCH v2 1/2] cpufreq: Add exit_prepare callback to " dirk.brandewie
2014-03-15 2:04 ` Rafael J. Wysocki
2014-03-18 5:43 ` Viresh Kumar
2014-03-14 21:03 ` [PATCH v2 2/2] intel_pstate: Set core to min P state during core offline dirk.brandewie
2014-03-18 5:44 ` Viresh Kumar
2014-03-18 15:01 ` Dirk Brandewie
2014-03-18 18:52 ` Srivatsa S. Bhat
2014-03-18 19:44 ` Dirk Brandewie
2014-03-18 20:15 ` Srivatsa S. Bhat
2014-03-19 5:20 ` Viresh Kumar
2014-03-19 15:32 ` Dirk Brandewie
2014-03-18 17:22 ` [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface dirk.brandewie
2014-03-18 17:22 ` [PATCH 1/2] cpufreq: Add stop callback to " dirk.brandewie
2014-03-19 5:04 ` Viresh Kumar
2014-03-18 17:22 ` [PATCH 2/2] intel_pstate: Set core to min P state during core offline dirk.brandewie
2014-03-18 19:08 ` Srivatsa S. Bhat
2014-03-18 19:08 ` Srivatsa S. Bhat [this message]
2014-03-18 19:25 ` [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface Dirk Brandewie
2014-03-18 20:04 ` Srivatsa S. Bhat
2014-03-19 0:53 ` Rafael J. Wysocki
2014-03-19 5:33 ` Viresh Kumar
2014-03-19 14:01 ` Rafael J. Wysocki
2014-03-19 13:49 ` Viresh Kumar
2014-03-19 14:25 ` 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=532899B2.2060106@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=dirk.brandewie@gmail.com \
--cc=dirk.j.brandewie@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=patrick.marlier@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.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).