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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJiuCcdSmgp75ByEDDtH0AtqGsUyc9QrAcD9xqLZduh2ijnrqQ@mail.gmail.com>
Date:   Mon, 4 May 2020 21:34:17 +0200
From:   Clément Péron <peron.clem@...il.com>
To:     Ondřej Jirman <megous@...ous.com>,
        Clément Péron <peron.clem@...il.com>,
        Maxime Ripard <mripard@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-kernel <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 Ondrej,

On Mon, 4 May 2020 at 14:27, Ondřej Jirman <megous@...ous.com> wrote:
>
> Hi Clément,
>

<snip>

>
> 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.

Thanks for the suggestion and I agree with you, this is a good way to
keep the same OPP table for all the H6 devices and handle both board
with PMIC and with fixed regulator.

I will propose a patch.

Thanks clement

>
> regards,
>         o.