Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency

From: Viresh Kumar
Date: Tue Aug 04 2020 - 01:25:17 EST


On 31-07-20, 13:14, Jon Hunter wrote:
> 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@xxxxxxxxx>
> Date: Mon Oct 13 08:37:40 2014 -0700
>
> cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
>
> Is this intentional?

Yes, it is.

There are two sysfs files to read the current frequency.

- scaling_cur_freq: as you noticed it returns cached value unless it is for
setpolicy drivers in whose case cpufreq core doesn't control the frequency and
so doesn't cache any values.

- cpuinfo_cur_freq: This will return the value as read from hardware using
->get() callback.

--
viresh