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

[Maxime Ripard <maxime.ripard@bootlin.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4025 bytes --]

On Tue, Apr 09, 2019 at 12:13:58AM +0800, Frank Lee wrote:
> On Fri, Apr 5, 2019 at 10:55 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Hi,
> >
> > On Fri, Apr 05, 2019 at 06:24:55AM -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.
> > >
> > > This change adds documentation for the DT bindings.
> > > The "operating-points-v2-sunxi-cpu" DT extends the "operating-points-v2"
> > > with following parameters:
> > > - nvmem-cells (NVMEM area containig the speedbin information)
> > > - opp-supported-hw: A single 32 bit bitmap value,
> > >   representing compatible HW:
> > >                       0:      speedbin 0
> > >                       1:      speedbin 1
> > >                       2:      speedbin 2
> > >                       3-31:   unused
> > >
> > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > ---
> > >  .../bindings/opp/sunxi-nvmem-cpufreq.txt      | 235 ++++++++++++++++++
> > >  1 file changed, 235 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt
> > > new file mode 100644
> > > index 000000000000..80201d4e5147
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt
> > > @@ -0,0 +1,235 @@
> > > +Allwinner Technologies, Inc. NVMEM CPUFreq and OPP bindings
> > > +===================================
> > > +
> > > +For some SoCs, the CPU frequency subset and voltage value of each OPP
> > > +varies based on the silicon variant in use. 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.
> > > +
> > > +Required properties:
> > > +--------------------
> > > +In 'cpus' nodes:
> > > +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> > > +
> > > +In 'operating-points-v2' table:
> > > +- compatible: Should be
> > > +     - 'operating-points-v2-sunxi-cpu'.
> > > +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
> > > +             efuse registers that has information about the
> > > +             speedbin that is used to select the right frequency/voltage
> > > +             value pair.
> > > +             Please refer the for nvmem-cells
> > > +             bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
> > > +             and also examples below.
> > > +
> > > +In every OPP node:
> > > +- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
> > > +                 Bitmap:
> > > +                     0:      speedbin 0
> > > +                     1:      speedbin 1
> > > +                     2:      speedbin 2
> > > +                     3-31:   unused
> >
> > I'm wondering if that's the right approach.
> >
> > I guess we could also have three different OPP tables, and pass them
> > all three through a phandle array, and have the kernel code select
> > which one is relevant based on the SID content
>
> It's ok. But why not use the way we already have?
> Is it necessary to introduce new helper?

My main concern is that it becomes quite difficult to differentiate
the various OPPs, and to which bin a particular OPP is belonging to,
while the more traditional OPPv2 makes it much more obvious.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel