linux-kernel - Re: [RFC/RFT v3 11/14] arm64: dts: meson-g12a: add cpus OPP table

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFBinCC1sJxBA8NgDNzLaWJV7Y+fARVczy31rHkbtkj58XKUUQ@mail.gmail.com>
Date:   Wed, 3 Jul 2019 14:12:21 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Neil Armstrong <narmstrong@...libre.com>
Cc:     jbrunet@...libre.com, khilman@...libre.com,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [RFC/RFT v3 11/14] arm64: dts: meson-g12a: add cpus OPP table

Hi Neil,

On Wed, Jul 3, 2019 at 1:53 PM Neil Armstrong <narmstrong@...libre.com> wrote:
>
> On 03/07/2019 01:47, Martin Blumenstingl wrote:
> > Hi Neil,
> >
> > On Mon, Jul 1, 2019 at 11:13 AM Neil Armstrong <narmstrong@...libre.com> wrote:
> >>
> >> Add the OPP table taken from the vendor u200 and u211 DTS.
> >>
> >> The Amlogic G12A SoC seems to available in 3 types :
> >> - low-speed: up to 1,8GHz
> >> - mid-speed: up to 1,908GHz
> >> - high-speed: up to 2.1GHz
> >>
> >> And the S905X2 opp voltages are slightly higher than the S905D2
> >> OPP voltages for the low-speed table.
> >>
> >> This adds the conservative OPP table with the S905X2 higher voltages
> >> and the maximum low-speed OPP frequency.
> > have you considered all three as separate voltage tables?
> > you're other patches are assigning the OPP table to the CPU in the
> > board.dts anyways, so it's easy to use different OPP tables for
> > different boards
>
> We can't assume the board and the CPU type :-/
OK, should we assign the OPP table to the CPU cores then in the
soc.dtsi (instead of board.dts like the other patches from this series
do)?

> Kevin told me about cpufreq policy, where we could add a policy reading the
> eFUSE and changing the max frequency, then we could add the whole OPP table.
we can still do that in a second step, so I'm all for starting with
the "conservative" OPP table and then improve performance (by having
detecting the SoC and using the correct OPP table)


Martin