From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Turquette <mike.turquette@linaro.org>
Subject: Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active
Date: Thu, 08 Oct 2015 10:23:49 +0100 [thread overview]
Message-ID: <1444296229.2847.9.camel@linaro.org> (raw)
In-Reply-To: <20151007173920.GG4557@linux>
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> And why not fix it properly by doing this:
>
> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
> index f1e42f8ce0fc..5b36657a76d6 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -128,7 +128,7 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
> static unsigned int
> bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> {
> - u32 new_rate, prev_rate;
> + u32 new_rate, prev_rate, target_rate;
> int ret;
> bool bLs = is_bL_switching_enabled();
>
> @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> per_cpu(physical_cluster, cpu) = new_cluster;
>
> new_rate = find_cluster_maxfreq(new_cluster);
> + target_rate = new_rate;
> new_rate = ACTUAL_FREQ(new_cluster, new_rate);
> } else {
> new_rate = rate;
> + target_rate = new_rate;
> }
>
> pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
> @@ -196,7 +198,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> * be reading only the cached value anyway. This needs to be removed
> * once clk core is fixed.
> */
> - if (bL_cpufreq_get_rate(cpu) != new_rate)
> + if (bL_cpufreq_get_rate(cpu) != target_rate)
> return -EIO;
> return 0;
> }
You call that a proper fix? ;-) It's comparing an 'virtual' frequency to
an 'actual' frequency.
If the real intent is to check that clk_set_rate works I would have
thought the patch below would be correct. But I didn't propose that as
it's the obvious implementation and I assumed the original patch didn't
do it that way for a reason.
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..59115a4 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -149,6 +149,18 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
__func__, cpu, old_cluster, new_cluster, new_rate);
ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
+ if (!ret) {
+ /*
+ * FIXME: clk_set_rate has to handle the case where clk_change_rate
+ * can fail due to hardware or firmware issues. Until the clk core
+ * layer is fixed, we can check here. In most of the cases we will
+ * be reading only the cached value anyway. This needs to be removed
+ * once clk core is fixed.
+ */
+ if (clk_get_rate(clk[new_cluster]) != new_rate * 1000)
+ ret = -EIO;
+ }
+
if (WARN_ON(ret)) {
pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret,
new_cluster);
@@ -189,15 +201,6 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
mutex_unlock(&cluster_lock[old_cluster]);
}
- /*
- * FIXME: clk_set_rate has to handle the case where clk_change_rate
- * can fail due to hardware or firmware issues. Until the clk core
- * layer is fixed, we can check here. In most of the cases we will
- * be reading only the cached value anyway. This needs to be removed
- * once clk core is fixed.
- */
- if (bL_cpufreq_get_rate(cpu) != new_rate)
- return -EIO;
return 0;
}
next prev parent reply other threads:[~2015-10-08 9:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 17:38 [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active Jon Medhurst (Tixy)
2015-10-07 17:39 ` Viresh Kumar
2015-10-08 9:23 ` Jon Medhurst (Tixy) [this message]
2015-10-08 11:24 ` Viresh Kumar
2015-10-08 12:55 ` Jon Medhurst (Tixy)
2015-10-08 13:52 ` Viresh Kumar
2015-10-08 14:18 ` Sudeep Holla
2015-10-12 13:20 ` Sudeep Holla
2015-10-13 7:19 ` Jon Medhurst (Tixy)
2015-10-13 10:36 ` Sudeep Holla
2015-10-14 7:12 ` Jon Medhurst (Tixy)
2015-10-14 8:48 ` Sudeep Holla
2015-10-19 8:33 ` Jon Medhurst (Tixy)
2015-10-19 8:44 ` Sudeep Holla
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=1444296229.2847.9.camel@linaro.org \
--to=tixy@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mike.turquette@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.