From: Jon Hunter <jonathanh@nvidia.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency
Date: Fri, 31 Jul 2020 13:14:09 +0100 [thread overview]
Message-ID: <8c6d3c32-c142-3981-3a52-6560e885f4c9@nvidia.com> (raw)
In-Reply-To: <20200714034635.2zdv3wzmftjg2t4a@vireshk-i7>
Hi Viresh,
On 14/07/2020 04:46, Viresh Kumar wrote:
...
> The get() callback is supposed to read the frequency from hardware and
> return it, no cached value here. policy->cur may end up being wrong in
> case there is a bug.
I have been doing some more testing on Tegra, I noticed that when
reading the current CPU frequency via the sysfs scaling_cur_freq entry,
this always returns the cached value (at least for Tegra). Looking at
the implementation of scaling_cur_freq I see ...
static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
{
ssize_t ret;
unsigned int freq;
freq = arch_freq_get_on_cpu(policy->cpu);
if (freq)
ret = sprintf(buf, "%u\n", freq);
else if (cpufreq_driver && cpufreq_driver->setpolicy &&
cpufreq_driver->get)
ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu));
else
ret = sprintf(buf, "%u\n", policy->cur);
return ret;
}
The various Tegra CPU frequency drivers do not implement the
set_policy callback and hence why we always get the cached value. I
see the following commit added this and before it simply return the
cached value ...
commit c034b02e213d271b98c45c4a7b54af8f69aaac1e
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Oct 13 08:37:40 2014 -0700
cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
Is this intentional?
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2020-07-31 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-12 10:06 [PATCH 1/2] cpufreq: tegra186: Fix initial frequency Jon Hunter
[not found] ` <20200712100645.13927-1-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-12 10:06 ` [PATCH 2/2] cpufreq: tegra186: Simplify probe return path Jon Hunter
[not found] ` <20200712100645.13927-2-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-13 3:28 ` Viresh Kumar
2020-07-13 3:25 ` [PATCH 1/2] cpufreq: tegra186: Fix initial frequency Viresh Kumar
2020-07-13 16:37 ` Jon Hunter
[not found] ` <3d6091f2-6b04-185f-6c23-e39a34b87877-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-14 3:46 ` Viresh Kumar
2020-07-14 7:26 ` Jon Hunter
[not found] ` <aa941c67-1dec-5363-7bd7-5e9d8d324110-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-07-14 7:31 ` Viresh Kumar
2020-07-31 12:14 ` Jon Hunter [this message]
2020-08-04 5:25 ` 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=8c6d3c32-c142-3981-3a52-6560e885f4c9@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=thierry.reding@gmail.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).