31 Dec, 2019
1 commit
-
[ Upstream commit c23734487fb44ee16c1b007ba72d793c085e4ec4 ]
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 binVendor 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
Signed-off-by: Ondrej Jirman
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
22 Jul, 2019
1 commit
-
For some SoCs, the CPU frequency subset and voltage value of each OPP
varies based on the silicon variant in use. The sun50i-cpufreq-nvmem
driver reads the efuse value from the SoC to provide the OPP framework
with required information.Signed-off-by: Yangtao Li
Acked-by: Maxime Ripard
Signed-off-by: Viresh Kumar
