Convert the ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit
(PMIC) Device Tree binding documentation to json-schema.
Make the "regulators" subnode optional, as not all users describe the
regulators.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
I have listed Marek as the maintainer, as he wrote the original
bindings. Marek: Please scream if this is inappropriate ;-)
v2:
- Add Reviewed-by.
---
.../devicetree/bindings/mfd/bd9571mwv.txt | 69 ----------
.../bindings/mfd/rohm,bd9571mwv.yaml | 127 ++++++++++++++++++
2 files changed, 127 insertions(+), 69 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
deleted file mode 100644
index 1d6413e96c376e4b..0000000000000000
--- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-* ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC) bindings
-
-Required properties:
- - compatible : Should be "rohm,bd9571mwv" or "rohm,bd9574mwf".
- - reg : I2C slave address.
- - interrupts : The interrupt line the device is connected to.
- - interrupt-controller : Marks the device node as an interrupt controller.
- - #interrupt-cells : The number of cells to describe an IRQ, should be 2.
- The first cell is the IRQ number.
- The second cell is the flags, encoded as trigger
- masks from ../interrupt-controller/interrupts.txt.
- - gpio-controller : Marks the device node as a GPIO Controller.
- - #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify flags.
- See ../gpio/gpio.txt for more information.
- - regulators: : List of child nodes that specify the regulator
- initialization data. Child nodes must be named
- after their hardware counterparts:
- - vd09
- - vd18
- - vd25
- - vd33
- - dvfs
- Each child node is defined using the standard
- binding for regulators.
-
-Optional properties:
- - rohm,ddr-backup-power : Value to use for DDR-Backup Power (default 0).
- This is a bitmask that specifies which DDR power
- rails need to be kept powered when backup mode is
- entered, for system suspend:
- - bit 0: DDR0
- - bit 1: DDR1
- - bit 2: DDR0C
- - bit 3: DDR1C
- These bits match the KEEPON_DDR* bits in the
- documentation for the "BKUP Mode Cnt" register.
- - rohm,rstbmode-level: The RSTB signal is configured for level mode, to
- accommodate a toggle power switch (the RSTBMODE pin is
- strapped low).
- - rohm,rstbmode-pulse: The RSTB signal is configured for pulse mode, to
- accommodate a momentary power switch (the RSTBMODE pin
- is strapped high).
- The two properties above are mutually exclusive.
-
-Example:
-
- pmic: pmic@30 {
- compatible = "rohm,bd9571mwv";
- reg = <0x30>;
- interrupt-parent = <&gpio2>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- rohm,ddr-backup-power = <0xf>;
- rohm,rstbmode-pulse;
-
- regulators {
- dvfs: dvfs {
- regulator-name = "dvfs";
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1030000>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
new file mode 100644
index 0000000000000000..89f9efee465b8ed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd9571mwv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC)
+
+maintainers:
+ - Marek Vasut <[email protected]>
+
+properties:
+ compatible:
+ enum:
+ - rohm,bd9571mwv
+ - rohm,bd9574mwf
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ rohm,ddr-backup-power:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0xf
+ description: |
+ Value to use for DDR-Backup Power (default 0).
+ This is a bitmask that specifies which DDR power rails need to be kept
+ powered when backup mode is entered, for system suspend:
+ - bit 0: DDR0
+ - bit 1: DDR1
+ - bit 2: DDR0C
+ - bit 3: DDR1C
+ These bits match the KEEPON_DDR* bits in the documentation for the "BKUP
+ Mode Cnt" register.
+
+ rohm,rstbmode-level:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The RSTB signal is configured for level mode, to accommodate a toggle
+ power switch (the RSTBMODE pin is strapped low).
+
+ rohm,rstbmode-pulse:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The RSTB signal is configured for pulse mode, to accommodate a momentary
+ power switch (the RSTBMODE pin is strapped high).
+
+ regulators:
+ type: object
+ description:
+ List of child nodes that specify the regulator initialization data.
+ Child nodes must be named after their hardware counterparts.
+
+ patternProperties:
+ "^(vd09|vd18|vd25|vd33|dvfs)$":
+ type: object
+ $ref: ../regulator/regulator.yaml#
+
+ properties:
+ regulator-name:
+ pattern: "^(vd09|vd18|vd25|vd33|dvfs)$"
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+oneOf:
+ - required:
+ - rohm,rstbmode-level
+ - required:
+ - rohm,rstbmode-pulse
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: pmic@30 {
+ compatible = "rohm,bd9571mwv";
+ reg = <0x30>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ rohm,ddr-backup-power = <0xf>;
+ rohm,rstbmode-pulse;
+
+ regulators {
+ dvfs: dvfs {
+ regulator-name = "dvfs";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1030000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
--
2.25.1
On 9/15/21 15:14, Geert Uytterhoeven wrote:
> Convert the ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit
> (PMIC) Device Tree binding documentation to json-schema.
>
> Make the "regulators" subnode optional, as not all users describe the
> regulators.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> ---
> I have listed Marek as the maintainer, as he wrote the original
> bindings. Marek: Please scream if this is inappropriate ;-)
>
> v2:
> - Add Reviewed-by.
> ---
> .../devicetree/bindings/mfd/bd9571mwv.txt | 69 ----------
> .../bindings/mfd/rohm,bd9571mwv.yaml | 127 ++++++++++++++++++
> 2 files changed, 127 insertions(+), 69 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
> + regulators {
> + dvfs: dvfs {
> + regulator-name = "dvfs";
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1030000>;
> + regulator-boot-on;
> + regulator-always-on;
Out of the curiosity (and in order to learn) - what is the exact idea of
the 'regulator-boot-on' and when it should be used? I _think_ the
'regulator-boot-on' is in many cases used to make the regulator
framework to enable the regulator at start-up. What I _think_ the
'regulator-boot-on' is intended for is to advertise the regulator
boot-up state for regulators which do not provide a way to get the
state. I am unsure if there is any property which is intended to be used
for enabling the regulator at start-up. DISCLAIMER: Source of these
thoughts is unknown. I may be wrong here. If someone knows this for sure
I'd be grateful for any education :) If I am not mistaken the dvfs
regulator does provide a way of reading the enable state after boot.
Finally, I have seen this quite many times before but I am unsure I
understand it - why setting both the 'regulator-boot-on' and
'regulator-always-on'? Wouldn't the 'regulator-always-on' suffice?
> + };
> + };
> + };
> + };
>
Anyways - as I mentioned, I am not 100% sure of pretty much anything :)
Hence my questions are just questions - and the binding looks good to me.
FWIW:
acked-by: Matti Vaittinen <[email protected]>
--Matti
Hi Matti,
On Thu, Sep 16, 2021 at 8:31 AM Vaittinen, Matti
<[email protected]> wrote:
> On 9/15/21 15:14, Geert Uytterhoeven wrote:
> > Convert the ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit
> > (PMIC) Device Tree binding documentation to json-schema.
> >
> > Make the "regulators" subnode optional, as not all users describe the
> > regulators.
> >
> > Signed-off-by: Geert Uytterhoeven <[email protected]>
> > Reviewed-by: Rob Herring <[email protected]>
> > ---
> > I have listed Marek as the maintainer, as he wrote the original
> > bindings. Marek: Please scream if this is inappropriate ;-)
> >
> > v2:
> > - Add Reviewed-by.
> > ---
> > .../devicetree/bindings/mfd/bd9571mwv.txt | 69 ----------
> > .../bindings/mfd/rohm,bd9571mwv.yaml | 127 ++++++++++++++++++
> > 2 files changed, 127 insertions(+), 69 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> > create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
> > + regulators {
> > + dvfs: dvfs {
> > + regulator-name = "dvfs";
> > + regulator-min-microvolt = <750000>;
> > + regulator-max-microvolt = <1030000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> Out of the curiosity (and in order to learn) - what is the exact idea of
> the 'regulator-boot-on' and when it should be used? I _think_ the
> 'regulator-boot-on' is in many cases used to make the regulator
> framework to enable the regulator at start-up. What I _think_ the
> 'regulator-boot-on' is intended for is to advertise the regulator
> boot-up state for regulators which do not provide a way to get the
> state. I am unsure if there is any property which is intended to be used
> for enabling the regulator at start-up. DISCLAIMER: Source of these
> thoughts is unknown. I may be wrong here. If someone knows this for sure
> I'd be grateful for any education :) If I am not mistaken the dvfs
> regulator does provide a way of reading the enable state after boot.
>
> Finally, I have seen this quite many times before but I am unsure I
> understand it - why setting both the 'regulator-boot-on' and
> 'regulator-always-on'? Wouldn't the 'regulator-always-on' suffice?
> > + };
> > + };
> > + };
> > + };
> >
>
> Anyways - as I mentioned, I am not 100% sure of pretty much anything :)
> Hence my questions are just questions - and the binding looks good to me.
I have to defer to the regulator experts to answer those questions...
> FWIW:
> acked-by: Matti Vaittinen <[email protected]>
s/a/A/
Thank you!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Sep 16, 2021 at 06:31:45AM +0000, Vaittinen, Matti wrote:
> 'regulator-boot-on' is in many cases used to make the regulator
> framework to enable the regulator at start-up. What I _think_ the
> 'regulator-boot-on' is intended for is to advertise the regulator
> boot-up state for regulators which do not provide a way to get the
It's for cases where we can't read the hardware state.