diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-07-28 14:45:03 +0200 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-07-30 14:26:51 +0200 |
commit | 4815d3c56d1e10449a44089a47544d9ba84fad0d (patch) | |
tree | 4b0c96b189ce8a66b7ded6301480a99489b2e9d2 /drivers/cpufreq | |
parent | 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9 (diff) | |
download | linux-4815d3c56d1e10449a44089a47544d9ba84fad0d.tar.bz2 |
cpufreq: x86: Make scaling_cur_freq behave more as expected
After commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to
calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute
in sysfs only behaves as expected on x86 with APERF/MPERF registers
available when it is read from at least twice in a row. The value
returned by the first read may not be meaningful, because the
computations in there use cached values from the previous iteration
of aperfmperf_snapshot_khz() which may be stale.
To prevent that from happening, modify arch_freq_get_on_cpu() to
call aperfmperf_snapshot_khz() twice, with a short delay between
these calls, if the previous invocation of aperfmperf_snapshot_khz()
was too far back in the past (specifically, more that 1s ago).
Also, as pointed out by Doug Smythies, aperf_delta is limited now
and the multiplication of it by cpu_khz won't overflow, so simplify
the s->khz computations too.
Fixes: f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF"
Reported-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq')
0 files changed, 0 insertions, 0 deletions