Re: [RFC PATCH v2 1/6] dt-bindings: ROHM BD96801 PMIC regulators

[Matti Vaittinen]

On 4/14/24 00:27, Krzysztof Kozlowski wrote:
> On 12/04/2024 13:21, Matti Vaittinen wrote:
> > ROHM BD96801 is a highly configurable automotive grade PMIC. Introduce
> > DT bindings for the BD96801 regulators.
> >
> > Signed-off-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
> > ---
> > Revision history:
> > - No changes since RFCv1
>
> Subject: missing "regulator" prefix, as first.
>
> >   .../regulator/rohm,bd96801-regulator.yaml     | 69 +++++++++++++++++++
> >   1 file changed, 69 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml
> > new file mode 100644
> > index 000000000000..4015802a3d84
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml
> > @@ -0,0 +1,69 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/regulator/rohm,bd96801-regulator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ROHM BD96801 Power Management Integrated Circuit regulators
> > +
> > +maintainers:
> > +  - Matti Vaittinen <matti.vaittinen@xxxxxxxxxxxxxxxxx>
> > +
> > +description: |
> > +  This module is part of the ROHM BD96801 MFD device. For more details
> > +  see Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml.
> > +
> > +  The regulator controller is represented as a sub-node of the PMIC node
> > +  on the device tree.
> > +
> > +  Regulator nodes should be named to BUCK_<number> and LDO_<number>.
> > +  The valid names for BD96801 regulator nodes are
> > +  BUCK1, BUCK2, BUCK3, BUCK4, LDO5, LDO6, LDO7
> > +
> > +patternProperties:
> > +  "^LDO[5-7]$":
>
> lowercase
>
> > +    type: object
> > +    description:
> > +      Properties for single LDO regulator.
> > +    $ref: regulator.yaml#
>
> Missing unevaluatedProperties: false
>
> > +
> > +    properties:
> > +      regulator-name:
> > +        pattern: "^ldo[5-7]$"
> > +        description:
> > +          Name of the regulator. Should be "ldo5", ..., "ldo7"
>
> Why do you enforce the name? The name should match board schematics, not
> regulator datasheet.

If my memory serves me right, the slightly peculiar thing with the 
regulator core is it does matching of the regulators based on the names 
of the nodes. There was the regulator-compatible property, but I think 
it has been deprecated long ago.

https://elixir.bootlin.com/linux/latest/source/drivers/regulator/of_regulator.c#L380

Hence the regulators tend to have fixed names for the nodes. Unless 
there has been some recent changes I am not aware of...

> > +      rohm,initial-voltage-microvolt:
> > +        description:
> > +          Initial voltage for regulator. Voltage can be tuned +/-150 mV from
> > +          this value. NOTE, This can be modified via I2C only when PMIC is in
> > +          STBY state.
> > +        minimum: 300000
> > +        maximum: 3300000
>
> Hm, regulator min/max microvolts properties don't work for you? The
> initial will be just middle?

I had not even thought of this!

I think this is a good idea. The problem I see is if the system where 
the PMIC is used will need to have 'initial power level' at start-up, 
which is near the one end of the allowed voltage area. (This because the 
"tuning"-range is quite narrow after the initial voltage is set). Wide 
allowed voltage range may be needed if the PMIC is reconfigured using 
the PMIC STBY state during the runtime.

Eg, sequence would look like:

Bootup:
PMIC STBY:
 - initial value 'A' from DT
=> PMIC ACTIVE
 - desired (early) voltages 'A' + 'tune'

..

Voltage state differing more than the 'tune' needed due to some runtime 
use-case:
=> PMIC STBY
 - initial value 'B'
=> PMIC ACTIVE
 - desired voltages 'B' + 'tune'

Now, if the 'A' can be 'far' from the mid point of the 'allowed 
voltages' -range.

I have no idea how valid this use-case is though. Once again, I work for 
a component vendor and don't get to see the forest from the trees... But 
sure I would like to enable as many possible use-cases as, well, possible :)

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~