* [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
@ 2020-08-10 7:06 Rajendra Nayak
2020-08-10 10:41 ` Sibi Sankar
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Rajendra Nayak @ 2020-08-10 7:06 UTC (permalink / raw)
To: vireshk, nm, sboyd, viresh.kumar
Cc: linux-pm, linux-kernel, linux-arm-msm, Rajendra Nayak
dev_pm_opp_set_rate() can now be called with freq = 0 inorder
to either drop performance or bandwidth votes or to disable
regulators on platforms which support them.
In such cases, a subsequent call to dev_pm_opp_set_rate() with
the same frequency ends up returning early because 'old_freq == freq'
Instead make it fall through and put back the dropped performance
and bandwidth votes and/or enable back the regulators.
Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes")
Reported-by: Sajida Bhanu <sbhanu@codeaurora.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
drivers/opp/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0c8c74a..a994f30 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -901,6 +901,9 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
/* Return early if nothing to do */
if (old_freq == freq) {
+ if (opp_table->required_opp_tables || opp_table->regulators ||
+ opp_table->paths)
+ goto skip_clk_only;
dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to do\n",
__func__, freq);
ret = 0;
@@ -919,6 +922,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
goto put_opp_table;
}
+skip_clk_only:
temp_freq = old_freq;
old_opp = _find_freq_ceil(opp_table, &temp_freq);
if (IS_ERR(old_opp)) {
@@ -954,8 +958,10 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
IS_ERR(old_opp) ? NULL : old_opp->supplies,
opp->supplies);
} else {
+ ret = 0;
/* Only frequency scaling */
- ret = _generic_set_opp_clk_only(dev, clk, freq);
+ if (freq != old_freq)
+ ret = _generic_set_opp_clk_only(dev, clk, freq);
}
/* Scaling down? Configure required OPPs after frequency */
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-10 7:06 [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early Rajendra Nayak
@ 2020-08-10 10:41 ` Sibi Sankar
2020-08-11 17:12 ` Matthias Kaehlcke
2020-08-11 21:09 ` Stephen Boyd
2 siblings, 0 replies; 7+ messages in thread
From: Sibi Sankar @ 2020-08-10 10:41 UTC (permalink / raw)
To: Rajendra Nayak
Cc: vireshk, nm, sboyd, viresh.kumar, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-msm-owner
On 2020-08-10 12:36, Rajendra Nayak wrote:
> dev_pm_opp_set_rate() can now be called with freq = 0 inorder
> to either drop performance or bandwidth votes or to disable
> regulators on platforms which support them.
> In such cases, a subsequent call to dev_pm_opp_set_rate() with
> the same frequency ends up returning early because 'old_freq == freq'
> Instead make it fall through and put back the dropped performance
> and bandwidth votes and/or enable back the regulators.
>
> Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to
> drop performance votes")
> Reported-by: Sajida Bhanu <sbhanu@codeaurora.org>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> drivers/opp/core.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 0c8c74a..a994f30 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -901,6 +901,9 @@ int dev_pm_opp_set_rate(struct device *dev,
> unsigned long target_freq)
>
> /* Return early if nothing to do */
> if (old_freq == freq) {
> + if (opp_table->required_opp_tables || opp_table->regulators ||
> + opp_table->paths)
> + goto skip_clk_only;
> dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to
> do\n",
> __func__, freq);
> ret = 0;
> @@ -919,6 +922,7 @@ int dev_pm_opp_set_rate(struct device *dev,
> unsigned long target_freq)
> goto put_opp_table;
> }
>
> +skip_clk_only:
> temp_freq = old_freq;
> old_opp = _find_freq_ceil(opp_table, &temp_freq);
> if (IS_ERR(old_opp)) {
> @@ -954,8 +958,10 @@ int dev_pm_opp_set_rate(struct device *dev,
> unsigned long target_freq)
> IS_ERR(old_opp) ? NULL : old_opp->supplies,
> opp->supplies);
> } else {
> + ret = 0;
> /* Only frequency scaling */
> - ret = _generic_set_opp_clk_only(dev, clk, freq);
> + if (freq != old_freq)
> + ret = _generic_set_opp_clk_only(dev, clk, freq);
> }
>
> /* Scaling down? Configure required OPPs after frequency */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-10 7:06 [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early Rajendra Nayak
2020-08-10 10:41 ` Sibi Sankar
@ 2020-08-11 17:12 ` Matthias Kaehlcke
2020-08-12 4:30 ` Rajendra Nayak
2020-08-11 21:09 ` Stephen Boyd
2 siblings, 1 reply; 7+ messages in thread
From: Matthias Kaehlcke @ 2020-08-11 17:12 UTC (permalink / raw)
To: Rajendra Nayak
Cc: vireshk, nm, sboyd, viresh.kumar, linux-pm, linux-kernel,
linux-arm-msm
On Mon, Aug 10, 2020 at 12:36:19PM +0530, Rajendra Nayak wrote:
> dev_pm_opp_set_rate() can now be called with freq = 0 inorder
> to either drop performance or bandwidth votes or to disable
> regulators on platforms which support them.
> In such cases, a subsequent call to dev_pm_opp_set_rate() with
> the same frequency ends up returning early because 'old_freq == freq'
> Instead make it fall through and put back the dropped performance
> and bandwidth votes and/or enable back the regulators.
>
> Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes")
> Reported-by: Sajida Bhanu <sbhanu@codeaurora.org>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Originally-reported-by: Matthias Kaehlcke <mka@chromium.org>
https://patchwork.kernel.org/patch/11675369/#23514895 :P
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-11 17:12 ` Matthias Kaehlcke
@ 2020-08-12 4:30 ` Rajendra Nayak
0 siblings, 0 replies; 7+ messages in thread
From: Rajendra Nayak @ 2020-08-12 4:30 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: vireshk, nm, sboyd, viresh.kumar, linux-pm, linux-kernel,
linux-arm-msm
On 8/11/2020 10:42 PM, Matthias Kaehlcke wrote:
> On Mon, Aug 10, 2020 at 12:36:19PM +0530, Rajendra Nayak wrote:
>> dev_pm_opp_set_rate() can now be called with freq = 0 inorder
>> to either drop performance or bandwidth votes or to disable
>> regulators on platforms which support them.
>> In such cases, a subsequent call to dev_pm_opp_set_rate() with
>> the same frequency ends up returning early because 'old_freq == freq'
>> Instead make it fall through and put back the dropped performance
>> and bandwidth votes and/or enable back the regulators.
>>
>> Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes")
>> Reported-by: Sajida Bhanu <sbhanu@codeaurora.org>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
>
> Originally-reported-by: Matthias Kaehlcke <mka@chromium.org>
> https://patchwork.kernel.org/patch/11675369/#23514895 :P
Sorry to have missed that :/
Thanks for testing.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-10 7:06 [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early Rajendra Nayak
2020-08-10 10:41 ` Sibi Sankar
2020-08-11 17:12 ` Matthias Kaehlcke
@ 2020-08-11 21:09 ` Stephen Boyd
2020-08-13 4:29 ` Viresh Kumar
2 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2020-08-11 21:09 UTC (permalink / raw)
To: Rajendra Nayak, nm, viresh.kumar, vireshk
Cc: linux-pm, linux-kernel, linux-arm-msm, Rajendra Nayak
Quoting Rajendra Nayak (2020-08-10 00:06:19)
> dev_pm_opp_set_rate() can now be called with freq = 0 inorder
> to either drop performance or bandwidth votes or to disable
> regulators on platforms which support them.
> In such cases, a subsequent call to dev_pm_opp_set_rate() with
> the same frequency ends up returning early because 'old_freq == freq'
> Instead make it fall through and put back the dropped performance
> and bandwidth votes and/or enable back the regulators.
>
> Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes")
> Reported-by: Sajida Bhanu <sbhanu@codeaurora.org>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> ---
> drivers/opp/core.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 0c8c74a..a994f30 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -901,6 +901,9 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>
> /* Return early if nothing to do */
> if (old_freq == freq) {
> + if (opp_table->required_opp_tables || opp_table->regulators ||
> + opp_table->paths)
> + goto skip_clk_only;
This is a goto maze! Any chance we can clean this up?
if (!opp_table->required_opp_tables && !opp_table->regulators &&
!opp_table->paths)
if (old_freq == freq) {
ret = 0
dev_dbg(..)
} else if (!_get_opp_count(opp_table)) {
ret = _generic_set_opp_clk_only(dev, clk, freq);
}
} else {
temp_freq = old_freq;
old_opp = _find_freq_ceil(opp_table, &temp_freq);
...
dev_pm_opp_put(opp);
put_old_opp:
if (!IS_ERR(old_opp))
dev_pm_opp_put(old_opp);
}
put_opp_table:
dev_pm_opp_put_opp_table(opp_table);
And that stuff in the else should probably go to another function.
> dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to do\n",
> __func__, freq);
> ret = 0;
> @@ -919,6 +922,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
> goto put_opp_table;
> }
>
> +skip_clk_only:
> temp_freq = old_freq;
> old_opp = _find_freq_ceil(opp_table, &temp_freq);
> if (IS_ERR(old_opp)) {
> @@ -954,8 +958,10 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
> IS_ERR(old_opp) ? NULL : old_opp->supplies,
> opp->supplies);
> } else {
> + ret = 0;
> /* Only frequency scaling */
> - ret = _generic_set_opp_clk_only(dev, clk, freq);
> + if (freq != old_freq)
> + ret = _generic_set_opp_clk_only(dev, clk, freq);
> }
And write this as
else if (freq != old_freq) {
ret = _generic_set_opp_clk_only(..)
} else {
ret = 0;
}
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-11 21:09 ` Stephen Boyd
@ 2020-08-13 4:29 ` Viresh Kumar
2020-08-16 12:30 ` Rajendra Nayak
0 siblings, 1 reply; 7+ messages in thread
From: Viresh Kumar @ 2020-08-13 4:29 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rajendra Nayak, nm, vireshk, linux-pm, linux-kernel,
linux-arm-msm
On 11-08-20, 14:09, Stephen Boyd wrote:
> This is a goto maze! Any chance we can clean this up?
I have sent a short series in reply to this series, please have a
look. It should look better now.
--
viresh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
2020-08-13 4:29 ` Viresh Kumar
@ 2020-08-16 12:30 ` Rajendra Nayak
0 siblings, 0 replies; 7+ messages in thread
From: Rajendra Nayak @ 2020-08-16 12:30 UTC (permalink / raw)
To: Viresh Kumar, Stephen Boyd
Cc: nm, vireshk, linux-pm, linux-kernel, linux-arm-msm
On 8/13/2020 9:59 AM, Viresh Kumar wrote:
> On 11-08-20, 14:09, Stephen Boyd wrote:
>> This is a goto maze! Any chance we can clean this up?
>
> I have sent a short series in reply to this series, please have a
> look. It should look better now.
Thanks, I was out a few days so could not get to the cleanups
that Stephen was suggesting.
I will give your series a try.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-08-16 12:31 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-10 7:06 [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early Rajendra Nayak
2020-08-10 10:41 ` Sibi Sankar
2020-08-11 17:12 ` Matthias Kaehlcke
2020-08-12 4:30 ` Rajendra Nayak
2020-08-11 21:09 ` Stephen Boyd
2020-08-13 4:29 ` Viresh Kumar
2020-08-16 12:30 ` Rajendra Nayak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox