linux-kernel - Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: Use dummy regulator for Tanix TX6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200504122742.er2jd67bvrn2rfgp@core.my.home>
Date:   Mon, 4 May 2020 14:27:42 +0200
From:   Ondřej Jirman <megous@...ous.com>
To:     Clément Péron <peron.clem@...il.com>
Cc:     Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Piotr Oniszczuk <warpme@...pl>
Subject: Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: Use dummy
 regulator for Tanix TX6

Hi Clément,

On Tue, Apr 28, 2020 at 04:26:29PM +0200, Clément Péron wrote:
> Tanix TX6 has a fixed regulator. As DVFS is instructed to change
> voltage to meet OPP table, the DVFS is not working as expected.
> 
> Avoid to introduce a new dedicated OPP Table where voltage are
> equals to the fixed regulator as it will only duplicate all the OPPs.
> Instead remove the fixed regulator so the DVFS framework will create
> dummy regulator and will have the same behavior.
> 
> Add some comments to explain this in the device-tree.
> 
> Reported-by: Piotr Oniszczuk <warpme@...pl>
> Fixes: add1e27fb703 ("arm64: dts: allwinner: h6: Enable CPU opp tables for Tanix TX6")
> Signed-off-by: Clément Péron <peron.clem@...il.com>
> ---
>  .../boot/dts/allwinner/sun50i-h6-tanix-tx6.dts | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> index be81330db14f..3e96fcb317ea 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> @@ -48,7 +48,15 @@
>  };
>  
>  &cpu0 {
> -	cpu-supply = <&reg_vdd_cpu_gpu>;
> +	/*
> +	 * Don't specify the CPU regulator, as it's a fixed
> +	 * regulator DVFS will not work as it is intructed
> +	 * to reach a voltage which can't be reached.
> +	 * Not specifying a regulator will create a dummy
> +	 * regulator allowing all OPPs.
> +	 *
> +	 * cpu-supply = <&reg_vdd_cpu_gpu>;
> +	 */

reg_vdd_cpu_gpu has 

    regulator-min-microvolt = <1135000>;
    regulator-max-microvolt = <1135000>;

top OPP is:

    opp@...0000000 {
            clock-latency-ns = <244144>; /* 8 32k periods */
            opp-hz = /bits/ 64 <1800000000>;

            opp-microvolt-speed0 = <1160000>;
            opp-microvolt-speed1 = <1100000>;
            opp-microvolt-speed2 = <1100000>;
    };

So I guess ignoring the voltage and not disabling this OPP may or may not work
based on SoC bin.

On Orange Pi One, there's a regulator that supports two voltages (that can't
support all the listed OPPs for H3), and cpufreq-dt can deal with that
automagically, if you specify OPP voltages via a tripplet of [prefered min max].
Kernell will log this in dmesg on boot:

[    0.672440] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator
[    0.672454] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000)
[    0.672523] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator
[    0.672530] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000)
[    0.672621] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator
[    0.672628] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000)
[    0.672712] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator
[    0.672719] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)

And the list of available OPPs will be reduced at runtime to a supportable
set by the CPU regulator.

If you look at:

  https://megous.com/git/linux/commit/?h=ths-5.7&id=d231770195913cf543c0cf9539deee2ecec06680

you'll see a bunch of OPPs for H3 that are specified as a range. So
for example if you want 480MHz, and your regulator can't produce
1.04V exactly, cpufreq will set the voltage to something supportable
in the range.

I think the proper fix is to fix the OPP table for H6, so that it uses
voltage ranges for each OPP and not a single fixed voltage, to support
boards that don't have the standard PMIC that goes with H6.

regards,
	o.

>  };
>  
>  &de {
> @@ -68,7 +76,13 @@
>  };
>  
>  &gpu {
> -	mali-supply = <&reg_vdd_cpu_gpu>;
> +	/*
> +	 * Don't specify the GPU regulator, see comment
> +	 * above for the CPU supply.
> +	 *
> +	 * mali-supply = <&reg_vdd_cpu_gpu>;
> +	 */
> +
>  	status = "okay";
>  };
>  
> -- 
> 2.20.1
> 
> -- 
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@...glegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200428142629.8950-1-peron.clem%40gmail.com.