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

[Frank Lee]

On Tue, Apr 30, 2019 at 12:42 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>
> On 29-04-19, 11:18, Rob Herring wrote:
> > On Sun, Apr 28, 2019 at 4:53 AM Frank Lee <tiny.windzz@xxxxxxxxx> wrote:
> > >
> > > On Sat, Apr 27, 2019 at 5:15 AM Rob Herring <robh@xxxxxxxxxx> 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