From: Saravana Kannan <skannan@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>, Bo Yan <byan@nvidia.com>,
sgurrappadi@nvidia.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended
Date: Thu, 15 Feb 2018 13:27:10 -0800 [thread overview]
Message-ID: <5A85FB2E.2050407@codeaurora.org> (raw)
In-Reply-To: <20180205090546.GE28462@vireshk-i7>
On 02/05/2018 01:05 AM, Viresh Kumar wrote:
> On 05-02-18, 09:50, Rafael J. Wysocki wrote:
>> By design (which I admit may be confusing) it should be fine to call
>> dpm_resume_end() after a failing dpm_suspend_start(), whatever the reason
>> for the failure is. cpufreq_suspend/resume() don't take that into account,
>> everybody else does.
>
> Hmm, I see. Can't do much then, just fix the only broken piece of code :)
>
Sorry for the late reply, this email didn't get filtered into the right
folder.
I think the design of dpm_suspend_start() and dpm_resume_end() generally
works fine because we seem to keep track of what devices have been
suspended so far (in the dpm_suspended_list) and call resume only of
those. So, why isn't the right fix to have cpufreq get put into that
list? Instead of just always call it on the resume path even if it
wasn't suspended? That seems to be the real issue.
So, we should either have dpm_suspend/resume() have a flag to keep track
of if cpufreq_suspend/resume() was called and make sure they are called
in proper pairs. Or have cpufreq register in a way that gets it put in
the suspend/resume list.
I'd still like to NACK this change.
-Saravana
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-02-15 21:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 21:57 [PATCH] cpufreq: skip cpufreq resume if it's not suspended Bo Yan
2018-01-24 2:02 ` Rafael J. Wysocki
2018-01-24 20:53 ` Bo Yan
2018-02-02 11:54 ` Rafael J. Wysocki
2018-02-02 19:34 ` Saravana Kannan
2018-02-02 21:28 ` Bo Yan
2018-02-05 4:01 ` Viresh Kumar
2018-02-05 8:50 ` Rafael J. Wysocki
2018-02-05 9:05 ` Viresh Kumar
2018-02-15 21:27 ` Saravana Kannan [this message]
2018-02-15 22:06 ` Rafael J. Wysocki
2018-01-25 19:15 ` [PATCH v2] " Bo Yan
2018-02-05 9:19 ` [PATCH] " Rafael J. Wysocki
2018-02-05 9:23 ` 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=5A85FB2E.2050407@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=byan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sgurrappadi@nvidia.com \
--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).