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
