11.11.2020 23:31, Jon Hunter пишет:
On 11/11/2020 13:47, Dmitry Osipenko wrote:
11.11.2020 13:38, Jon Hunter пишет:
Commit 9ce274630495 ("cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)") update the Tegra20 CPUFREQ driver to use the generic CPUFREQ device-tree driver. Since this change CPUFREQ support on the Tegra20 Ventana platform has been broken because the necessary device-tree nodes with the operating point information are not populated for this platform. Fix this by updating device-tree for Venata to include the operating point informration for Tegra20.
Fixes: 9ce274630495 ("cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)") Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter jonathanh@nvidia.com
arch/arm/boot/dts/tegra20-ventana.dts | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts index b158771ac0b7..055334ae3d28 100644 --- a/arch/arm/boot/dts/tegra20-ventana.dts +++ b/arch/arm/boot/dts/tegra20-ventana.dts @@ -3,6 +3,7 @@ #include <dt-bindings/input/input.h> #include "tegra20.dtsi" +#include "tegra20-cpu-opp.dtsi" / { model = "NVIDIA Tegra20 Ventana evaluation board"; @@ -592,6 +593,16 @@ clk32k_in: clock@0 { #clock-cells = <0>; };
- cpus {
cpu0: cpu@0 {operating-points-v2 = <&cpu0_opp_table>;};cpu@1 {operating-points-v2 = <&cpu0_opp_table>;};- };
- gpio-keys { compatible = "gpio-keys";
This could be wrong to do because CPU voltage is fixed to 1000mV in Ventana's DT, are you sure that higher clock rates don't require higher voltages? What is the CPU process ID and SoC speedo ID on Ventana?
I see this in the bootlog ...
[ 2.797684] tegra20-cpufreq tegra20-cpufreq: hardware version 0x2 0x2
You could easily hook up CPU voltage scaling, please see acer-500 DT and patch [1] for examples of how to set up regulators in DT. But then it shouldn't be a stable patch.
According to the Ventana design guide the CPU voltage range is 0.8-1.0V and so it appears to be set to the max. The CPUFREQ test is reporting the following ...
cpu: cpufreq: - CPU#0: cpu: cpufreq: - supported governors: cpu: cpufreq: - ondemand * cpu: cpufreq: - performance cpu: cpufreq: - schedutil cpu: cpufreq: - supported rates: cpu: cpufreq: - 216000 cpu: cpufreq: - 312000 cpu: cpufreq: - 456000 cpu: cpufreq: - 608000 cpu: cpufreq: - 760000 cpu: cpufreq: - 816000 cpu: cpufreq: - 912000 cpu: cpufreq: - 1000000 * cpu: cpufreq: - CPU#1: cpu: cpufreq: - supported governors: cpu: cpufreq: - ondemand * cpu: cpufreq: - performance cpu: cpufreq: - schedutil cpu: cpufreq: - supported rates: cpu: cpufreq: - 216000 cpu: cpufreq: - 312000 cpu: cpufreq: - 456000 cpu: cpufreq: - 608000 cpu: cpufreq: - 760000 cpu: cpufreq: - 816000 cpu: cpufreq: - 912000 cpu: cpufreq: - 1000000 *
If you don't see a message in KMSG saying "bringing vdd_cpu to 1000000uV", then should be good.