linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema
@ 2021-09-15 12:14 Geert Uytterhoeven
  2021-09-16  6:31 ` Vaittinen, Matti
  0 siblings, 1 reply; 4+ messages in thread
From: Geert Uytterhoeven @ 2021-09-15 12:14 UTC (permalink / raw)
  To: Rob Herring, Marek Vasut, Matti Vaittinen, Lee Jones,
	Liam Girdwood, Mark Brown
  Cc: devicetree, linux-renesas-soc, linux-kernel, Geert Uytterhoeven,
	Rob Herring

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 <geert+renesas@glider.be>
Reviewed-by: Rob Herring <robh@kernel.org>
---
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 <marek.vasut@gmail.com>
+
+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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema
  2021-09-15 12:14 [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema Geert Uytterhoeven
@ 2021-09-16  6:31 ` Vaittinen, Matti
  2021-09-16  6:35   ` Geert Uytterhoeven
  2021-09-16 11:20   ` Mark Brown
  0 siblings, 2 replies; 4+ messages in thread
From: Vaittinen, Matti @ 2021-09-16  6:31 UTC (permalink / raw)
  To: Geert Uytterhoeven, Rob Herring, Marek Vasut, Lee Jones,
	Liam Girdwood, Mark Brown
  Cc: devicetree, linux-renesas-soc, linux-kernel, Rob Herring

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 <geert+renesas@glider.be>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> 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 <matti.vaittinen@fi.rohmeurope.com>

--Matti


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema
  2021-09-16  6:31 ` Vaittinen, Matti
@ 2021-09-16  6:35   ` Geert Uytterhoeven
  2021-09-16 11:20   ` Mark Brown
  1 sibling, 0 replies; 4+ messages in thread
From: Geert Uytterhoeven @ 2021-09-16  6:35 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: Rob Herring, Marek Vasut, Lee Jones, Liam Girdwood, Mark Brown,
	devicetree, linux-renesas-soc, linux-kernel, Rob Herring

Hi Matti,

On Thu, Sep 16, 2021 at 8:31 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> 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 <geert+renesas@glider.be>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > 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 <matti.vaittinen@fi.rohmeurope.com>

s/a/A/

Thank you!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema
  2021-09-16  6:31 ` Vaittinen, Matti
  2021-09-16  6:35   ` Geert Uytterhoeven
@ 2021-09-16 11:20   ` Mark Brown
  1 sibling, 0 replies; 4+ messages in thread
From: Mark Brown @ 2021-09-16 11:20 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: Geert Uytterhoeven, Rob Herring, Marek Vasut, Lee Jones,
	Liam Girdwood, devicetree, linux-renesas-soc, linux-kernel,
	Rob Herring

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

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.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-09-16 11:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-15 12:14 [PATCH v2] dt-bindings: mfd: bd9571mwv: Convert to json-schema Geert Uytterhoeven
2021-09-16  6:31 ` Vaittinen, Matti
2021-09-16  6:35   ` Geert Uytterhoeven
2021-09-16 11:20   ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).