From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Subject: Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set
Date: Fri, 8 Apr 2016 11:14:14 +0530 [thread overview]
Message-ID: <20160408054414.GE9674@vireshk-i7> (raw)
In-Reply-To: <2346918.2NTGrKGAVB@vostro.rjw.lan>
On 08-04-16, 00:05, Rafael J. Wysocki wrote:
> On Thursday, April 07, 2016 05:35:03 PM Viresh Kumar wrote:
> > That's *ugly* and it works by chance, unless I am misreading it
> > completely.
>
> I'm assuming that what you mean by "ugly" here is "not really straightforward",
> which I agree with,
Yeah.
> but then it is really disappointing to see comments like
> that from you about the code that you helped to write.
I was just trying to say that this isn't how I feel it should be done.
:(
> Moreover, runtime CPU offline *also* doesn't have to run the governor exit/init
> for the same reason why the policy directory doesn't have to be removed on
> CPU offline: it is just pointless to do that. The governor has been stopped
> already and it won't do anything more. The only problem here is to prevent
> governor tunable sysfs attributes from triggering actions in that state,
> but that shouldn't be too difficult to arrange for. If that's done,
Isn't that already guaranteed as userspace should have been frozen by
by the time we reach cpufreq_suspend()?
> cpufreq_suspended can be dropped, modulo changing cpufreq_start_governor()
> to return immediately if the governor has been started already.
>
> And if something else is needed to protect driver callbacks from being invoked
> outside of the suspend-resume path, a more robust mechanism has to be added
> for that.
>
> But in the meantime, I'd like to address the fast switch problem first and
> then you're free to clean up things on top of that. Or I will clean them up
> if I have the time.
Okay..
--
viresh
next prev parent reply other threads:[~2016-04-08 5:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 1:29 [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set Rafael J. Wysocki
2016-04-07 4:28 ` Viresh Kumar
2016-04-07 11:22 ` Rafael J. Wysocki
2016-04-07 11:32 ` Viresh Kumar
2016-04-07 11:44 ` Rafael J. Wysocki
2016-04-07 12:05 ` Viresh Kumar
2016-04-07 22:05 ` Rafael J. Wysocki
2016-04-08 5:44 ` Viresh Kumar [this message]
2016-04-08 21:56 ` Rafael J. Wysocki
2016-04-08 5:45 ` Viresh Kumar
2016-04-08 21:54 ` Rafael J. Wysocki
2016-04-10 3:16 ` Viresh Kumar
2016-04-10 3:46 ` Rafael J. Wysocki
2016-04-10 4:08 ` [PATCH] cpufreq: Abort cpufreq_update_current_freq() " Rafael J. Wysocki
2016-04-10 4:10 ` Viresh Kumar
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=20160408054414.GE9674@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.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