aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm
diff options
context:
space:
mode:
authorOndrej Jirman <megous@megous.com>2019-11-01 17:41:51 +0100
committerViresh Kumar <viresh.kumar@linaro.org>2019-11-05 15:06:49 +0530
commitc23734487fb44ee16c1b007ba72d793c085e4ec4 (patch)
tree7af36f341e9d0b570647b76ad639ee86e252e89f /arch/arm
parentcpufreq: vexpress-spc: find and skip duplicates when merging frequencies (diff)
downloadlinux-dev-c23734487fb44ee16c1b007ba72d793c085e4ec4.tar.xz
linux-dev-c23734487fb44ee16c1b007ba72d793c085e4ec4.zip
cpufreq: sun50i: Fix CPU speed bin detection
I have observed failures to boot on Orange Pi 3, because this driver determined that my SoC is from the normal bin, but my SoC only works reliably with the OPP values for the slowest bin. By querying H6 owners, it was found that e-fuse values found in the wild are in the range of 1-3, value of 7 was not reported, yet. From this and from unused defines in BSP code, it can be assumed that meaning of efuse values on H6 actually is: - 1 = slowest bin - 2 = normal bin - 3 = fastest bin Vendor code actually treats 0 and 2 as invalid efuse values, but later treats all invalid values as a normal bin. This looks like a mistake in bin detection code, that was plastered over by a hack in cpufreq code, so let's not repeat it here. It probably only works because there are no SoCs in the wild with efuse value of 0, and fast bin SoCs are made to use normal bin OPP tables, which is also safe. Let's play it safe and interpret 0 as the slowest bin, but fix detection of other bins to match this research. More research will be done before actual OPP tables are merged. Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver") Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'arch/arm')
0 files changed, 0 insertions, 0 deletions