linux-kernel - Re: [PATCH v3 2/2] dt-bindings: cpufreq: Document allwinner,cpu-operating-points-v2

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: <CAEExFWsAQ3b42YqfW-b8vuq_NZgfDe+0D5TzP09ber0Ljvv43g@mail.gmail.com>
Date:   Wed, 1 May 2019 11:44:55 +0800
From:   Frank Lee <tiny.windzz@...il.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rob Herring <robh@...nel.org>, Viresh Kumar <vireshk@...nel.org>,
        Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Chen-Yu Tsai <wens@...e.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        David Miller <davem@...emloft.net>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] dt-bindings: cpufreq: Document allwinner,cpu-operating-points-v2

On Tue, Apr 30, 2019 at 12:42 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 29-04-19, 11:18, Rob Herring wrote:
> > On Sun, Apr 28, 2019 at 4:53 AM Frank Lee <tiny.windzz@...il.com> wrote:
> > >
> > > On Sat, Apr 27, 2019 at 5:15 AM Rob Herring <robh@...nel.org> wrote:
> > > >
> > > > On Wed, Apr 10, 2019 at 01:41:39PM -0400, Yangtao Li wrote:
> > > > > Allwinner Process Voltage Scaling Tables defines the voltage and
> > > > > frequency value based on the speedbin blown in the efuse combination.
> > > > > The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to
> > > > > provide the OPP framework with required information.
> > > > > This is used to determine the voltage and frequency value for each
> > > > > OPP of operating-points-v2 table when it is parsed by the OPP framework.
> > > > >
> > > > > The "allwinner,cpu-operating-points-v2" DT extends the "operating-points-v2"
> > > > > with following parameters:
> > > > > - nvmem-cells (NVMEM area containig the speedbin information)
> > > > > - opp-microvolt-<name>: voltage in micro Volts.
> > > > >   At runtime, the platform can pick a <name> and matching
> > > > >   opp-microvolt-<name> property.
> > > > >                       HW:             <name>:
> > > > >                       sun50iw-h6      speed0 speed1 speed2
> > > >
> > > > We already have at least one way to support speed bins with QC kryo
> > > > binding. Why do we need a different way?
> > >
> > > For some SOCs, for some reason (making the CPU have approximate performance),
> > > they use the same frequency but different voltage. In the case where
> > > this speed bin
> > > is not a lot and opp uses the same frequency, too many repeated opp
> > > nodes are a bit
> > > redundant and not intuitive enough.
> > >
> > > So, I think it's worth the new method.
> >
> > Well, I don't.
> >
> > We can't have every SoC vendor doing their own thing just because they
> > want to. If there are technical reasons why existing bindings don't
> > work, then maybe we need to do something different. But I haven't
> > heard any reasons.
>
> Well there is a good reason for attempting the new bindings and I wasn't sure if
> updating the earlier bindings or adding another one for platform is correct. As
> we aren't really adding new bindings, but just documentation around it.
We didn't really add anything else, it still revolves around the
features that opp already supports.
>
> So there are two ways OPP core support this thing:
>
> - opp-supported-hw: This is a better fit if we have a smaller group of
>   frequencies to select from a bigger group, so we disable non-required OPPs
>   completely. This is what Qcom did as they wanted to select different
>   frequencies all together.
>
> - opp-microvolt-<name>: This is a better fit if the frequencies remain same and
>   only few of the properties like voltage/current have a different value. So we
>   don't disable any OPPs but just select the right voltage/current for those
>   frequencies. This avoids unnecessary duplication of the OPPs in DT and that's
>   what allwinner guys want.
>
> The kryo nvmem bindings currently supports opp-supported-hw, maybe we can add
> mention support for second one in the same file and rename it well.
So which way is correct?

Thx,
Yangtao
>
> --
> viresh