The ROHM BD72720 is a power management IC integrating regulators, GPIOs,
charger, LEDs, RTC and a clock gate.
Add dt-binding doc for ROHM BD72720.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
.../bindings/mfd/rohm,bd72720-pmic.yaml | 269 ++++++++++++++++++
1 file changed, 269 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
new file mode 100644
index 000000000000..7f8168410121
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
@@ -0,0 +1,269 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd72720-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD72720 Power Management Integrated Circuit
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ BD72720 is a single-chip power management IC for battery-powered portable
+ devices. The BD72720 integrates 10 bucks and 11 LDOs, and a 3000 mA
+ switching charger. The IC also includes a Coulomb counter, a real-time
+ clock (RTC), GPIOs and a 32.768 kHz clock gate.
+
+# In addition to the properties found from the charger node, the ROHM BD72720
+# uses properties from a static battery node. Please see the:
+# Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml
+#
+# Following properties are used
+# when present:
+#
+# charge-full-design-microamp-hours: Battry capacity in mAh
+# voltage-max-design-microvolt: Maximum voltage
+# voltage-min-design-microvolt: Minimum voltage system is still operating.
+# degrade-cycle-microamp-hours: Capacity lost due to aging at each full
+# charge cycle.
+# ocv-capacity-celsius: Array of OCV table temperatures. 1/table.
+# ocv-capacity-table-<N>: Table of OCV voltage/SOC pairs. Corresponds
+# N.th temperature in ocv-capacity-celsius
+#
+# ROHM specific properties:
+# rohm,voltage-vdr-thresh-microvolt: Threshold for starting the VDR correction
+# rohm,volt-drop-soc: Table of capacity values matching the
+# values in VDR tables.
+# rohm,volt-drop-high-temp-microvolt: VDR table for high temperature
+# rohm,volt-drop-normal-temp-microvolt: VDR table for normal temperature
+# rohm,volt-drop-low-temp-microvolt: VDR table for low temperature
+# rohm,volt-drop-very-low-temp-microvolt: VDR table for very low temperature
+#
+# VDR tables are (usually) determined for a specific battery by ROHM.
+# The battery node would then be referred from the charger node:
+#
+# monitored-battery = <&battery>;
+
+properties:
+ compatible:
+ const: rohm,bd72720
+
+ reg:
+ description:
+ I2C slave address.
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ The first cell is the pin number and the second cell is used to specify
+ flags. See ../gpio/gpio.txt for more information.
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ const: bd71828-32k-out
+
+ rohm,clkout-open-drain:
+ description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+
+ rohm,charger-sense-resistor-milli-ohms:
+ minimum: 10
+ maximum: 50
+ description: |
+ BD72720 has a SAR ADC for measuring charging currents. External sense
+ resistor (RSENSE in data sheet) should be used. If some other but
+ 30 mOhm resistor is used the resistance value should be given here in
+ milli Ohms.
+
+ regulators:
+ $ref: ../regulator/rohm,bd77270-regulator.yaml
+ description:
+ List of child nodes that specify the regulators.
+
+ leds:
+ $ref: ../leds/rohm,bd71828-leds.yaml
+
+ rohm,pin-dvs0:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ BD72720 has 4 different OTP options to determine the use of dvs0-pin.
+ OTP0 - regulator RUN state control.
+ OTP1 - GPI.
+ OTP2 - GPO.
+ OTP3 - Power sequencer output.
+ This property specifies the use of the pin.
+ enum:
+ - dvs-input
+ - gpi
+ - gpo
+
+ rohm,pin-dvs1:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ see rohm,pin-dvs0
+ enum:
+ - dvs-input
+ - gpi
+ - gpo
+
+ rohm,pin-exten0:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: BD72720 has an OTP option to use exten0-pin for different
+ purposes. Set this property accrdingly.
+ const: gpo
+
+ rohm,pin-exten1:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: BD72720 has an OTP option to use exten1-pin for different
+ purposes. Set this property accrdingly.
+ const: gpo
+
+ rohm,pin-fault_b:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: BD72720 has an OTP option to use fault_b-pin for different
+ purposes. Set this property accrdingly.
+ const: gpo
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - "#clock-cells"
+ - regulators
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic: pmic@4b {
+ compatible = "rohm,bd71828";
+ reg = <0x4b>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+ clocks = <&osc 0>;
+ #clock-cells = <0>;
+ clock-output-names = "bd71828-32k-out";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-reserved-ranges = <0 1>, <2 1>;
+
+ rohm,charger-sense-resistor-ohms = <10000000>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <2500>;
+ };
+ buck2: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <2500>;
+ };
+ buck3: BUCK3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <2000000>;
+ };
+ buck4: BUCK4 {
+ regulator-name = "buck4";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ buck5: BUCK5 {
+ regulator-name = "buck5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ buck6: BUCK6 {
+ regulator-name = "buck6";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <2500>;
+ };
+ buck7: BUCK7 {
+ regulator-name = "buck7";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <2500>;
+ };
+ ldo1: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo2: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo3: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo4: LDO4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo5: LDO5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo6: LDO6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ ldo7_reg: LDO7 {
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+
+ leds {
+ compatible = "rohm,bd71828-leds";
+
+ led-1 {
+ rohm,led-compatible = "bd71828-grnled";
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+ led-2 {
+ rohm,led-compatible = "bd71828-ambled";
+ function = LED_FUNCTION_CHARGING;
+ color = <LED_COLOR_ID_AMBER>;
+ };
+ };
+ };
+ };
--
2.51.0
Hi Matti, thanks for your patch! On Tue, Oct 7, 2025 at 10:33 AM Matti Vaittinen <mazziesaccount@gmail.com> wrote: > + rohm,pin-dvs0: > + $ref: /schemas/types.yaml#/definitions/string > + description: > + BD72720 has 4 different OTP options to determine the use of dvs0-pin. > + OTP0 - regulator RUN state control. > + OTP1 - GPI. > + OTP2 - GPO. > + OTP3 - Power sequencer output. > + This property specifies the use of the pin. > + enum: > + - dvs-input > + - gpi > + - gpo > + > + rohm,pin-dvs1: > + $ref: /schemas/types.yaml#/definitions/string > + description: > + see rohm,pin-dvs0 > + enum: > + - dvs-input > + - gpi > + - gpo > + > + rohm,pin-exten0: > + $ref: /schemas/types.yaml#/definitions/string > + description: BD72720 has an OTP option to use exten0-pin for different > + purposes. Set this property accrdingly. accordingly? > + const: gpo > + > + rohm,pin-exten1: > + $ref: /schemas/types.yaml#/definitions/string > + description: BD72720 has an OTP option to use exten1-pin for different > + purposes. Set this property accrdingly. accordingly? > + const: gpo > + > + rohm,pin-fault_b: > + $ref: /schemas/types.yaml#/definitions/string > + description: BD72720 has an OTP option to use fault_b-pin for different > + purposes. Set this property accrdingly. accordingly? > + const: gpo These are a bit idiomatic, not using the actual framework for such things (pin control) BUT: they are on the other hand crystal clear for an integrator working with this device tree, and only four pins so why over-engineer it. I am fine with them if the DT people are. Yours, Linus Walleij
On 13/10/2025 15:58, Linus Walleij wrote: > Hi Matti, > > thanks for your patch! Thank You for taking the time to review of this RFC! > On Tue, Oct 7, 2025 at 10:33 AM Matti Vaittinen > <mazziesaccount@gmail.com> wrote: > >> + rohm,pin-dvs0: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + BD72720 has 4 different OTP options to determine the use of dvs0-pin. >> + OTP0 - regulator RUN state control. >> + OTP1 - GPI. >> + OTP2 - GPO. >> + OTP3 - Power sequencer output. >> + This property specifies the use of the pin. >> + enum: >> + - dvs-input >> + - gpi >> + - gpo >> + >> + rohm,pin-dvs1: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + see rohm,pin-dvs0 >> + enum: >> + - dvs-input >> + - gpi >> + - gpo >> + >> + rohm,pin-exten0: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: BD72720 has an OTP option to use exten0-pin for different >> + purposes. Set this property accrdingly. > > accordingly? > >> + const: gpo >> + >> + rohm,pin-exten1: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: BD72720 has an OTP option to use exten1-pin for different >> + purposes. Set this property accrdingly. > > accordingly? > >> + const: gpo >> + >> + rohm,pin-fault_b: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: BD72720 has an OTP option to use fault_b-pin for different >> + purposes. Set this property accrdingly. > > accordingly? Gah. Well spotted, thanks! > >> + const: gpo > > These are a bit idiomatic, not using the actual framework for such > things (pin control) BUT: they are on the other hand crystal > clear for an integrator working with this device tree, and only > four pins so why over-engineer it. I am fine > with them if the DT people are. I kind of like to emphasize the fact that this is not really a pin-mux in a traditional sense. We can't change the routing after OTP is written. As such, it more resembles "wiring" of the signal inside the PMIC, and this property is not a control but tells us how the signal is wired. But yeah, let's see what others think of it. Yours, -- Matti
On Tue, Oct 14, 2025 at 2:11 PM Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > These are a bit idiomatic, not using the actual framework for such > > things (pin control) BUT: they are on the other hand crystal > > clear for an integrator working with this device tree, and only > > four pins so why over-engineer it. I am fine > > with them if the DT people are. > > I kind of like to emphasize the fact that this is not really a pin-mux > in a traditional sense. We can't change the routing after OTP is > written. As such, it more resembles "wiring" of the signal inside the > PMIC, and this property is not a control but tells us how the signal is > wired. But yeah, let's see what others think of it. Just that the muxing is controlled by OTP and not by runtime software doesn't make it not pinmux. It is, because it is (one time) PROGRAMMED to a certain purpose. In a factory, nevertheless. But the pin control muxing subsystem is designed for muxing that is controlled by software at runtime, and as such, indeed not a good fit. Let's go with this! Yours, Linus Walleij
© 2016 - 2026 Red Hat, Inc.