Skip to contentSkip to conversation

Support ROHM BD73800

PATCH Applied Matti Vaittinen 6 participants 27 messages Aug 4 – Sep 23

Subsystems (7)

v2 of 4 Applied Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v2 cover Support ROHM BD73800

Add support for the ROHM BD73800 PMIC and compatibles.

The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4 LDOs. There is also an ADC and operation amplifier intended for current / temperature measurement and accumulation. RTC and 32.768 kHz clock gate are also included. The PMIC can be customized via OTP and it has options for operating as a main PMIC in multi-PMIC installation. Some of the pins can also be used for GPO or GPI (including interrupt support).

There are also ROHM BD71851 and BD71885 PMICs out there. These are, from the SW-perspective, similar to the BD73800. There is only some different default values and OTP settings. The driver should be able to handle them just fine.

Revision history:

v1 => v2:
- Rebased on regulator/for-7.3 as it carries dependency:
f29a8bf6fde1 ("regulator: dt-bindings: ROHM PMIC state-machine voltages")
- dt-bindings: Various fixes, split generic stuff to own files.
- gpio: Styling, return -ENODEV if no GPIOs found
- MFD: Styling
- regulator: Simplify dt-reading
More accurate change-log in individual patches.

---

Matti Vaittinen (10):
dt-bindings: mfd: common ROHM PMIC properties
dt-bindings: rohm,bd*: Ref common ROHM bindings
dt-bindings: regulator: ROHM BD73800 regulators
dt-bindings: mfd: ROHM BD73800 PMIC
mfd: Support for ROHM BD73800 PMIC core
rtc: bd70528: Support RTC on ROHM BD73800
regulator: bd71828: Support ROHM BD73800
clk: bd718x7: Support ROHM BD73800
gpio: bd73800: Support ROHM BD73800 PMIC GPIOs
MAINTAINERS: Add ROHM BD73800 PMIC files

 .../bindings/mfd/rohm,bd71815-pmic.yaml       |   9 +-
 .../bindings/mfd/rohm,bd71828-pmic.yaml       |   9 +-
 .../bindings/mfd/rohm,bd72720-pmic.yaml       |  29 +-
 .../bindings/mfd/rohm,bd73800-pmic.yaml       | 218 +++++++
 .../bindings/mfd/rohm,pmic-pins.yaml          |  72 +++
 .../regulator/rohm,bd73800-regulator.yaml     |  99 ++++
 MAINTAINERS                                   |   2 +
 drivers/clk/clk-bd718x7.c                     |   8 +
 drivers/gpio/Kconfig                          |  11 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-bd73800.c                   | 227 +++++++
 drivers/mfd/Kconfig                           |  15 +-
 drivers/mfd/rohm-bd71828.c                    | 147 ++++-
 drivers/regulator/Kconfig                     |   4 +-
 drivers/regulator/bd71828-regulator.c         | 558 +++++++++++++++++-
 drivers/rtc/rtc-bd70528.c                     |   8 +
 include/linux/mfd/rohm-bd73800.h              | 307 ++++++++++
 include/linux/mfd/rohm-generic.h              |   1 +
 18 files changed, 1679 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml
 create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml
 create mode 100644 drivers/gpio/gpio-bd73800.c
 create mode 100644 include/linux/mfd/rohm-bd73800.h

base-commit: 36c3ea84289913d16dd2ed783534193c957055b9

Signature · 1 line
2.55.0
#1 lore raw

PATCH v2 1/10 dt-bindings: mfd: common ROHM PMIC properties

From: Matti Vaittinen <[email protected]>

ROHM PMICs keep having similar functionalities from one generation to the next. Keeping the device-trees describing these functionalities similar helps users because:
1. They can re-use existing device-tree properties when switching from one project, using a ROHM PMIC, to next project using newer variant.
2. The users can find and re-use examples from old projects - even if they never worked with ROHM PMICs before.
Similarly, introducing new and different properties for same functionality previous variant had, will be adding confusion.

Sometimes the existing properties aren't 100% what reviewers would prefer. When issues are minor or just cosmetic, changing the existing properties is not feasible. Reviewers can't be expected to know which properties are new, and which are existing - and this can lead to unnecessary review discussion wasting time and energy from everyone.

Adding a common file for re-used ROHM PMIC properties should make it clearly visible that a property is re-used, when a new PMIC binding refers to this file instead of (re-)describing all the existing bindings. This will also help keeping the common properties identical across the variants.

Add new file listing commonly used ROHM PMIC properties.

---
Revision history:
v2:
- New patch

---
 .../bindings/mfd/rohm,pmic-pins.yaml          | 72 +++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml
Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml new file +72 -0
new file mode 100644
index 000000000000..0d1082804f5a
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,pmic-pins.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM PMICs' OTP configured pin descriptions
+
+maintainers:
+  - Matti Vaittinen <[email protected]>
+
+description:
+  Collection of properties which are commonly used to describe various
+  ROHM PMIC's pins.
+
+properties:
+  rohm,clkout-open-drain:
+    description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos"
+      a.k.a "push-pull".
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 1
+
+  rohm,pin-clkout:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      The IC has different OTP options to use clkout-pin for different
+      purposes. Set this property to indicate the OTP variant.
+
+      Many of the ROHM ICs have pins, which function can be defined in
+      OTP. Some of them provide no means to detect the pin configuration
+      at run-time, leaving software unaware of which features the IC
+      really has. These properties can be used to inform which pins
+      provide which functionality. IOW, these properties aren't used to
+      configure pin, they are used to tell what functionality pins on
+      this specific IC have.
+
+    # Supported functionalities depend on the exact IC model. Following
+    # values are already defined: gpi, gpo.
+    # Please, re-use them when adding new ICs.
+
+  rohm,pin-fault_b:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      The IC has different OTP options to use fault_b-pin for different
+      purposes. Set this property to indicate the OTP variant.
+
+    # Supported functionalities depend on the exact IC model. Following
+    # values are already defined: gpi, gpo, faultb, readyind, pwrseq.
+    # Please, re-use them when adding new ICs.
+
+patternProperties:
+  "^rohm,pin-dvs[0-1]$":
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      The IC has different OTP options to use dvs<X>-pins for different
+      purposes. Set this property to indicate the OTP variant.
+    # Supported functionalities depend on the exact IC model. Following
+    # values are already defined: dvs-input, gpi, gpo, pwrseq.
+    # Please, re-use them when adding new ICs.
+
+  "^rohm,pin-exten([0-1])?$":
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      The IC has an OTP option to use exten -pin(s) for different purposes.
+      Set this property to indicate the OTP variant.
+    # Supported functionalities depend on the exact IC model. Following
+    # values are already defined: gpi, gpo, pwrseq.
+    # Please, re-use them when adding new ICs.
+
+# The schema is expected to be reference by IC schemas, which may introduce
+# other properties that must be allowed.
+additionalProperties: true
Signature · 1 line
2.55.0
maintainer
#2 lore raw

Re: [PATCH v2 01/10] dt-bindings: mfd: common ROHM PMIC properties

Hi Matti,

thanks for your patch (and the other comments in reply to the old review).

Quoted 6 lines · Matti Vaittinen

Sometimes the existing properties aren't 100% what reviewers would prefer. When issues are minor or just cosmetic, changing the existing properties is not feasible. Reviewers can't be expected to know which properties are new, and which are existing - and this can lead to unnecessary review discussion wasting time and energy from everyone.

Quoted 7 lines

Adding a common file for re-used ROHM PMIC properties should make it clearly visible that a property is re-used, when a new PMIC binding refers to this file instead of (re-)describing all the existing bindings. This will also help keeping the common properties identical across the variants.

Add new file listing commonly used ROHM PMIC properties.

I see the upside of this, the DT binding maintainers will decide on it. It has the upside you describe, but it has the downside that new components will always (ab-)use the old properties maybe even when there would be a good opportunity to modernize the syntax, and then the reviewers will not catch it.

But well, maybe that is not a big deal in the universe.

What about patching those old bindings:
Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml:
rohm,clkout-open-drain:
Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml:
rohm,clkout-open-drain:
Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml:
rohm,clkout-open-drain:
...to include this file as part of this patch, and delete the old defines from those three files?

Then it is clear what is going on.

Maybe this happens in later patches, but anyway it should be part of this patch I think.

Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml line 21

Quoted 6 lines
Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml new file +6 -0
+properties:
+  rohm,clkout-open-drain:
+    description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos"
+      a.k.a "push-pull".
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 1

Yeah I see now that this is already in use in three other bindings...

Today we would for a new component use something like rohm,clkout-drive-mode = "drive-push-pull"; rohm,clkout-drive-mode = "drive-open-drain"; reflecting pin control.

I do understand the idea to keep using the same bindings for all of Rohm MFDs. But when a completely new design arrives with many new properties etc, maybe we can think of something new?

Yours,
Linus Walleij

maintainer
#3 lore raw

Re: [PATCH v2 01/10] dt-bindings: mfd: common ROHM PMIC properties

Quoted 4 lines · Linus Walleij

Hi Matti,

thanks for your patch (and the other comments in reply to the old review).

Nope. Thank You for taking the time to do the review - and read my replies!

Quoted 16 lines
Quoted 12 lines · Matti Vaittinen

Sometimes the existing properties aren't 100% what reviewers would prefer. When issues are minor or just cosmetic, changing the existing properties is not feasible. Reviewers can't be expected to know which properties are new, and which are existing - and this can lead to unnecessary review discussion wasting time and energy from everyone.

Adding a common file for re-used ROHM PMIC properties should make it clearly visible that a property is re-used, when a new PMIC binding refers to this file instead of (re-)describing all the existing bindings. This will also help keeping the common properties identical across the variants.

Quoted 7 lines
Quoted 1 line

Add new file listing commonly used ROHM PMIC properties.

I see the upside of this, the DT binding maintainers will decide on it. It has the upside you describe, but it has the downside that new components will always (ab-)use the old properties maybe even when there would be a good opportunity to modernize the syntax, and then the reviewers will not catch it.

I see your point :) I am not intending to "completely hide" these properties from the reviewers. Please, see below.

Quoted 11 lines

But well, maybe that is not a big deal in the universe.

What about patching those old bindings:
Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml:
rohm,clkout-open-drain:
Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml:
rohm,clkout-open-drain:
Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml:
rohm,clkout-open-drain:
...to include this file as part of this patch, and delete the old defines from those three files?

I am patching them. I, however, am not planning to delete the properties completely (the comment above about not hiding properties from reviewers). For example, the bd71815 and bd71828, do not support (at least all) of the OTP configured pins which are also declared here. Thus, I don't want to allow those unsupported pin properties for them.

My plan is to keep the "additionalProperties: false", and require the supported properties to be explicitly listed in the rohm,bd71828-pmic.yaml and rohm,bd72720-pmic.yaml. And, when the types, descriptions, and allowed values (when common for all PMICs) are in the referenced file, the rohm,bdXXXX-pmic.yaml can become quite simple:

rohm,clkout-open-drain: true;

Enough to remind reviewers that there is legacy - and allow reviewers as well as authors to re-evaluate the properties - while also pointing out that this is existing stuff. (And allow validator scripts to catch use of unsupported common properties - at least if this works as I think it does).

Quoted 4 lines

Then it is clear what is going on.

Maybe this happens in later patches, but anyway it should be part of this patch I think.

I somehow thought it'd be clearer to split the changes in own patches - but I am fully Ok with squashing these if it is preferred way.

Quoted 14 lines

Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml line 21

Quoted 6 lines
Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml new file +6 -0
+properties:
+  rohm,clkout-open-drain:
+    description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos"
+      a.k.a "push-pull".
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 1

Yeah I see now that this is already in use in three other bindings...

Today we would for a new component use something like rohm,clkout-drive-mode = "drive-push-pull"; rohm,clkout-drive-mode = "drive-open-drain"; reflecting pin control.

Quoted 4 lines

I do understand the idea to keep using the same bindings for all of Rohm MFDs. But when a completely new design arrives with many new properties etc, maybe we can think of something new?

In case of the "rohm,clkout-open-drain" - AFAIR it is not used from new drivers, but the new PMICs which are added, are supported by the same MFD driver. I am not too keen on changing the property values in this driver (because it'd require every user to update their dtses - which feels like a source of problems). Nor am I too excited about supporting old and new values in this driver as it makes the driver (in my opinion unnecessarily) more complex.

What comes to using something else for completely new designs - I'd say (a bit cautiously) that changing the properties there is fine. Cautiously because it is still dancing between "what users have used to see" Vs. "what feels like best course of action - Today" ;) Cautiously also because we don't probably want to support multiple vendor specific properties for same purpose - at least not in a long run.

Yours,
-- Matti

Ps, planning to join ELCE/Plumbers this year? It'd be about a time to meet you in person :)

Signature · 5 lines
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~
maintainer Reviewed-by on v2 1/10
#4 lore raw

Re: [PATCH v2 01/10] dt-bindings: mfd: common ROHM PMIC properties

In reply to Matti Vaittinen
Quoted 29 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

ROHM PMICs keep having similar functionalities from one generation to the next. Keeping the device-trees describing these functionalities similar helps users because:
1. They can re-use existing device-tree properties when switching from one project, using a ROHM PMIC, to next project using newer variant.
2. The users can find and re-use examples from old projects - even if they never worked with ROHM PMICs before.
Similarly, introducing new and different properties for same functionality previous variant had, will be adding confusion.

Sometimes the existing properties aren't 100% what reviewers would prefer. When issues are minor or just cosmetic, changing the existing properties is not feasible. Reviewers can't be expected to know which properties are new, and which are existing - and this can lead to unnecessary review discussion wasting time and energy from everyone.

Adding a common file for re-used ROHM PMIC properties should make it clearly visible that a property is re-used, when a new PMIC binding refers to this file instead of (re-)describing all the existing bindings. This will also help keeping the common properties identical across the variants.

Add new file listing commonly used ROHM PMIC properties.

Quoted 9 lines

---
Revision history:
v2:
- New patch

---
 .../bindings/mfd/rohm,pmic-pins.yaml          | 72 +++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,pmic-pins.yaml
maintainer Reviewed-by on v2 1/10
#5 lore raw

Re: [PATCH v2 01/10] dt-bindings: mfd: common ROHM PMIC properties

In reply to Matti Vaittinen
Quoted 25 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

ROHM PMICs keep having similar functionalities from one generation to the next. Keeping the device-trees describing these functionalities similar helps users because:
1. They can re-use existing device-tree properties when switching from one project, using a ROHM PMIC, to next project using newer variant.
2. The users can find and re-use examples from old projects - even if they never worked with ROHM PMICs before.
Similarly, introducing new and different properties for same functionality previous variant had, will be adding confusion.

Sometimes the existing properties aren't 100% what reviewers would prefer. When issues are minor or just cosmetic, changing the existing properties is not feasible. Reviewers can't be expected to know which properties are new, and which are existing - and this can lead to unnecessary review discussion wasting time and energy from everyone.

Adding a common file for re-used ROHM PMIC properties should make it clearly visible that a property is re-used, when a new PMIC binding refers to this file instead of (re-)describing all the existing bindings. This will also help keeping the common properties identical across the variants.

Quoted 3 lines

Add new file listing commonly used ROHM PMIC properties.

DT maintainers think it's fine in two patches so:

Yours,
Linus Walleij

#6 lore raw

PATCH v2 2/10 dt-bindings: rohm,bd*: Ref common ROHM bindings

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The commonly used ROHM PMIC bindings were added into rohm,pmic-pins.yaml. Keeping commonly used properties in one file can ease both the maintaining the bindings and the reviewing process.

Reference the common bindings from rohm,pmic-pins.yaml, instead of declaring them from the scratch for every PMIC using them. Keep the PMIC variant specific information (like supported pin functions) in PMIC the specific files, so unsupported values won't be allowed.

---
Revision history:
v2:
- New patch

---
 .../bindings/mfd/rohm,bd71815-pmic.yaml       |  9 +++---
 .../bindings/mfd/rohm,bd71828-pmic.yaml       |  9 +++---
 .../bindings/mfd/rohm,bd72720-pmic.yaml       | 29 +++----------------
 3 files changed, 12 insertions(+), 35 deletions(-)
Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml +4 -5
index 4fc78efaa550..0a67de054674 100644
@@ -15,6 +15,9 @@ description: |
   for LED and a 500 mA single-cell linear charger. Also included is a Coulomb
   counter, a real-time clock (RTC), and a 32.768 kHz clock gate and two GPOs.
 
+allOf:
+  - $ref: rohm,pmic-pins.yaml#
+
 properties:
   compatible:
     const: rohm,bd71815
@@ -44,11 +47,7 @@ properties:
   clock-output-names:
     const: bd71815-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,clkout-open-drain: true
 
   rohm,charger-sense-resistor-micro-ohms:
     minimum: 10000
Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml +4 -5
index 09e7d68e92bf..e5043dec990d 100644
@@ -15,6 +15,9 @@ description: |
   single-cell linear charger. Also included is a Coulomb counter, a real-time
   clock (RTC), and a 32.768 kHz clock gate.
 
+allOf:
+  - $ref: rohm,pmic-pins.yaml#
+
 properties:
   compatible:
     oneOf:
@@ -49,11 +52,7 @@ properties:
   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,clkout-open-drain: true
 
   rohm,charger-sense-resistor-micro-ohms:
     minimum: 10000
Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml +4 -25
index b094542339e8..52d0f6e4ef0f 100644
@@ -15,6 +15,9 @@ description:
   and a 3000 mA switching charger. ICs also include a Coulomb counter,
   a real-time clock (RTC), GPIOs and a 32.768 kHz clock gate.
 
+allOf:
+  - $ref: rohm,pmic-pins.yaml#
+
 # In addition to the properties found from the charger node, PMICs
 # use properties from a static battery node. Please see the:
 # Documentation/devicetree/bindings/power/supply/battery.yaml
@@ -80,10 +83,7 @@ properties:
   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
-    maximum: 1
+  rohm,clkout-open-drain: true
 
   rohm,charger-sense-resistor-micro-ohms:
     minimum: 10000
@@ -103,14 +103,6 @@ properties:
     $ref: /schemas/leds/rohm,bd71828-leds.yaml
 
   rohm,pin-fault_b:
-    $ref: /schemas/types.yaml#/definitions/string
-    description:
-      PMIC has an OTP option to use fault_b-pin for different
-      purposes. Set this property accordingly. OTP options are
-      OTP0 - bi-directional FAULT_B or READY indicator depending on a
-      'sub option'
-      OTP1 - GPO
-      OTP2 - Power sequencer output.
     enum:
       - faultb
       - readyind
@@ -119,14 +111,6 @@ properties:
 
 patternProperties:
   "^rohm,pin-dvs[0-1]$":
-    $ref: /schemas/types.yaml#/definitions/string
-    description:
-      PMIC has 4 different OTP options to determine the use of dvs<X>-pins.
-      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
@@ -134,11 +118,6 @@ patternProperties:
       - pwrseq
 
   "^rohm,pin-exten[0-1]$":
-    $ref: /schemas/types.yaml#/definitions/string
-    description: PMIC has an OTP option to use exten0-pin for different
-      purposes. Set this property accordingly.
-      OTP0 - GPO
-      OTP1 - Power sequencer output.
     enum:
       - gpo
       - pwrseq
Signature · 1 line
2.55.0
maintainer Reviewed-by on v2 2/10
#7 lore raw

Re: [PATCH v2 02/10] dt-bindings: rohm,bd*: Ref common ROHM bindings

Quoted 17 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The commonly used ROHM PMIC bindings were added into rohm,pmic-pins.yaml. Keeping commonly used properties in one file can ease both the maintaining the bindings and the reviewing process.

Reference the common bindings from rohm,pmic-pins.yaml, instead of declaring them from the scratch for every PMIC using them. Keep the PMIC variant specific information (like supported pin functions) in PMIC the specific files, so unsupported values won't be allowed.

---
Revision history:
v2:
- New patch

Quoted 6 lines
---
 .../bindings/mfd/rohm,bd71815-pmic.yaml       |  9 +++---
 .../bindings/mfd/rohm,bd71828-pmic.yaml       |  9 +++---
 .../bindings/mfd/rohm,bd72720-pmic.yaml       | 29 +++----------------
 3 files changed, 12 insertions(+), 35 deletions(-)
maintainer Reviewed-by on v2 2/10
#8 lore raw

Re: [PATCH v2 02/10] dt-bindings: rohm,bd*: Ref common ROHM bindings

In reply to Matti Vaittinen
Quoted 6 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The commonly used ROHM PMIC bindings were added into rohm,pmic-pins.yaml. Keeping commonly used properties in one file can ease both the maintaining the bindings and the reviewing process.

Quoted 6 lines

Reference the common bindings from rohm,pmic-pins.yaml, instead of declaring them from the scratch for every PMIC using them. Keep the PMIC variant specific information (like supported pin functions) in PMIC the specific files, so unsupported values won't be allowed.

Yours,
Linus Walleij

#9 lore raw

PATCH v2 3/10 dt-bindings: regulator: ROHM BD73800 regulators

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

Add bindings for the BUCKs and LDOs on ROHM BD73800. The PMIC state specific voltages can be set in same fashion as with a few other ROHM PMICs (for example with BD718[15,28,37,47,50,79]). Same properties are recycled :)

The LDOs 1 and 4 can use different voltage ranges depending on the OTP configuration.

---
Revision history:
v1 => v2:
- Description of the state specific voltages moved to own file and referenced from it (because multiple PMIC bindings used them).

The dt checker's documentation reference checker warns about the link to the MFD binding - which will be introduced in next commit. These commits have kind of a chicken and egg issue as MFD is referencing regulator properties introduced in this patch.

I could squash these but IMO, this is clearer for the reviewers. AFAICS, Both MFD and regulator subsystems tend to be busy. I could also split adding the MFD comment reference to own patch which would be after the patch adding the MFD binding, but having own patch for just adding the comment is a bit meh.

So, I decided to live with the broken doc-link between these two patches.

---
 .../regulator/rohm,bd73800-regulator.yaml     | 99 +++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml
Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml new file +99 -0
new file mode 100644
index 000000000000..2db4585272c5
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/rohm,bd73800-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD73800 Power Management Integrated Circuit regulators
+
+maintainers:
+  - Matti Vaittinen <[email protected]>
+
+description: |
+  This module is part of the ROHM BD73800 MFD device. For more details
+  see Documentation/devicetree/bindings/mfd/rohm,bd73800-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 BD73800 regulator nodes are
+  buck1, buck2, buck3, buck4, buck5, buck6, buck7, buck8
+  ldo1, ldo2, ldo3, ldo4
+
+patternProperties:
+  "^buck[1-8]$":
+    type: object
+    description:
+      Properties for a single BUCK regulator.
+    allOf:
+      - $ref: regulator.yaml#
+      - $ref: rohm,pmic-states.yaml#
+
+    properties:
+      regulator-name:
+        pattern: "^buck[1-8]$"
+        description:
+          should be "buck1", ..., "buck8"
+
+      rohm,dvs-run-voltage:
+        minimum: 0
+        maximum: 3500000
+
+      rohm,dvs-idle-voltage:
+        minimum: 0
+        maximum: 3500000
+
+      rohm,dvs-suspend-voltage:
+        minimum: 0
+        maximum: 3500000
+
+        # BUCKs 1,2,3,4 and 8 support voltages 0.5 - 1.3V
+        # BUCK 5 supports voltages 0.3 - 1.3V
+        # BUCKs 6 and 7 support voltages 1.5 - 3.5V
+
+    required:
+      - regulator-name
+
+    unevaluatedProperties: false
+
+  "^ldo[1-4]$":
+    type: object
+    description:
+      Properties for single LDO regulator.
+    allOf:
+      - $ref: regulator.yaml#
+      - $ref: rohm,pmic-states.yaml#
+
+    properties:
+      regulator-name:
+        pattern: "^ldo[1-4]$"
+        description:
+          should be "ldo1", ..., "ldo4"
+
+      rohm,dvs-run-voltage:
+        minimum: 0
+        maximum: 1
+
+      rohm,dvs-idle-voltage:
+        minimum: 0
+        maximum: 1
+
+      rohm,dvs-suspend-voltage:
+        minimum: 0
+        maximum: 1
+
+      rohm,ldo-range-high:
+        type: boolean
+        description:
+          LDO1 and LDO3 voltage ranges can be "high" or "low" depending on
+          OTP. Indicate that the "high" range is used. See comment below
+          for voltages.
+
+        # LDOs 2 and 4 support voltages 0.75 - 3.3V
+        # LDOs 1 and 3 may support different ranges depending on OTP.
+        # either 0.6 - 1.8V or 0.75 - 3.3V.
+
+    unevaluatedProperties: false
+
+additionalProperties: false
Signature · 1 line
2.55.0
#10 lore raw

Re: [PATCH v2 03/10] dt-bindings: regulator: ROHM BD73800 regulators

Quoted 29 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

Add bindings for the BUCKs and LDOs on ROHM BD73800. The PMIC state specific voltages can be set in same fashion as with a few other ROHM PMICs (for example with BD718[15,28,37,47,50,79]). Same properties are recycled :)

The LDOs 1 and 4 can use different voltage ranges depending on the OTP configuration.

---
Revision history:
v1 => v2:
- Description of the state specific voltages moved to own file and referenced from it (because multiple PMIC bindings used them).

The dt checker's documentation reference checker warns about the link to the MFD binding - which will be introduced in next commit. These commits have kind of a chicken and egg issue as MFD is referencing regulator properties introduced in this patch.

I could squash these but IMO, this is clearer for the reviewers. AFAICS, Both MFD and regulator subsystems tend to be busy. I could also split adding the MFD comment reference to own patch which would be after the patch adding the MFD binding, but having own patch for just adding the comment is a bit meh.

Quoted 7 lines

So, I decided to live with the broken doc-link between these two patches.

---
 .../regulator/rohm,bd73800-regulator.yaml     | 99 +++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml: Unresolvable reference: rohm,pmic-states.yaml#

doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml Documentation/devicetree/bindings/regulator/rohm,bd73800-regulator.yaml: Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml

See https://patchwork.kernel.org/project/devicetree/patch/e1ada83ee4bdc1d1718fa81c335c741771ab57c3.1785838585.git.mazziesaccount@gmail.com

The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

#11 lore raw

PATCH v2 4/10 dt-bindings: mfd: ROHM BD73800 PMIC

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4 LDOs. There is also an ADC and operation amplifier intended for current / temperature measurement and accumulation. RTC and 32.768 kHz clock gate are also included. The PMIC can be customized via OTP and it has options for operating as a main PMIC in multi-PMIC installation. Some of the pins can also be used for GPO or GPI (including interrupt support).

There are also ROHM BD71851 and BD71885 PMICs out there. These are, from the SW-perspective, similar to the BD73800. There is only some different default values and OTP settings. The driver should be able to handle them just fine.

---
Revision history:
v1 => v2:
- Reference commonly used ROHM bindings from a common binding file
- Simplify compatible list
- Move relevant comments to description so they can be shown in generated human-readable doc.
- Allow other clock-output-names besides "bd73800-32k-out"

---
 .../bindings/mfd/rohm,bd73800-pmic.yaml       | 218 ++++++++++++++++++
 1 file changed, 218 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml new file +218 -0
new file mode 100644
index 000000000000..8371e7f2ab84
@@ -0,0 +1,218 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD73800 Power Management Integrated Circuit
+
+maintainers:
+  - Matti Vaittinen <[email protected]>
+
+description:
+  BD73800GW is a single-chip power management IC for battery-powered
+  portable devices. It integrates 8 buck converters, 4 LDOs and a current
+  sense amplifier with ADC. Also included is a Real Time Clock (RTC) and a
+  32.768 kHz clock gate. Depending on the OTP configuration the BD73800
+  may also have interrupt controller and GPIOs.
+
+  There are also different variants called BD71851 and BD71885 which are
+  almost identical from the software point of view.
+
+allOf:
+  - $ref: rohm,pmic-pins.yaml#
+
+properties:
+  compatible:
+    oneOf:
+      - const: rohm,bd73800
+
+      - items:
+          - enum:
+              - rohm,bd71851
+              - rohm,bd71885
+          - const: rohm,bd73800
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  # The GPIO1, CLKOUT (GPIO2), FAULT_B and EXTEN_OUT pins can be
+  # configured to interrupt pins by OTP.
+  interrupt-controller: true
+
+  "#interrupt-cells":
+    const: 1
+    description:
+      The IRQ number. 0 is GPIO1, 1 CLKOUT (GPIO2), 2 FAULT_B and 3 EXTEN_OUT.
+      NOTE, A pin can operate as IRQ source only when the OTP
+      configuration for it has been set to GPI.
+
+  gpio-controller: true
+
+  "#gpio-cells":
+    const: 2
+
+  rohm,pin-gpio1:
+    $ref: /schemas/types.yaml#/definitions/string
+    description:
+      Indicate if the GPIO1 pin has been set to GPI or GPO at manufacturing.
+      The GPIO1, CLKOUT, FAULT_B and EXTEN_OUT pins may be configured for a
+      specific purpose (like ADC input, 32.768 clk output, fault indicator or
+      delivering power sequence to a companion PMIC when multiple PMICs are
+      used) - but also to be either a GPO or GPI. (When used as a GPI the pin
+      can also be used as an IRQ source). The pin purpose is determined by
+      OTP (One Time Programmable memory), typically during device
+      manufacturing. The OTP can't be read at runtime so device-tree should
+      describe the GPIO pins.
+    enum: [gpi, gpo]
+
+  rohm,pin-clkout:
+    enum: [gpi, gpo]
+
+  rohm,pin-fault_b:
+    enum: [gpi, gpo]
+
+  rohm,pin-exten:
+    enum: [gpi, gpo]
+
+  clocks:
+    description:
+      The CLKOUT pin may have its purpose overridden by OTP configuration. It
+      is possible the BD73800 does not output a clock signal. Hence the clk
+      properties are optional.
+    maxItems: 1
+
+  "#clock-cells":
+    const: 0
+
+  clock-output-names:
+    maxItems: 1
+
+  rohm,clkout-open-drain: true
+
+  regulators:
+    $ref: /schemas/regulator/rohm,bd73800-regulator.yaml
+    description:
+      List of child nodes that specify the regulators.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - regulators
+
+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,bd73800";
+            reg = <0x4b>;
+
+            interrupt-parent = <&gpio1>;
+            interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+            clocks = <&osc 0>;
+            #clock-cells = <0>;
+            clock-output-names = "bd73800-32k-out";
+
+            gpio-controller;
+            #gpio-cells = <2>;
+
+            rohm,pin-gpio1 = "gpo";
+            rohm,pin-exten = "gpi";
+
+            regulators {
+                buck1: buck1 {
+                    regulator-name = "buck1";
+                    regulator-min-microvolt = <800000>;
+                    regulator-max-microvolt = <2000000>;
+                    regulator-always-on;
+                    regulator-ramp-delay = <1250>;
+                    rohm,dvs-run-voltage = <1150000>;
+                    rohm,dvs-suspend-voltage = <950000>;
+                };
+                buck2: buck2 {
+                    regulator-name = "buck2";
+                    regulator-min-microvolt = <800000>;
+                    regulator-max-microvolt = <2000000>;
+                    regulator-always-on;
+                    regulator-ramp-delay = <1250>;
+                    rohm,dvs-run-voltage = <1150000>;
+                    rohm,dvs-suspend-voltage = <950000>;
+                };
+                buck3: buck3 {
+                    regulator-name = "buck3";
+                    regulator-min-microvolt = <1200000>;
+                    regulator-max-microvolt = <2700000>;
+                    rohm,dvs-run-voltage = <1150000>;
+                    rohm,dvs-idle-voltage = <1100000>;
+                    rohm,dvs-suspend-voltage = <950000>;
+                    regulator-always-on;
+                };
+                buck4: buck4 {
+                    regulator-name = "buck4";
+                    regulator-min-microvolt = <1100000>;
+                    regulator-max-microvolt = <1850000>;
+                    regulator-always-on;
+                };
+                buck5: buck5 {
+                    regulator-name = "buck5";
+                    regulator-min-microvolt = <1800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                buck6: buck6 {
+                    regulator-name = "buck6";
+                    regulator-min-microvolt = <1800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                buck7: buck7 {
+                    regulator-name = "buck7";
+                    regulator-min-microvolt = <1800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                buck8: buck8 {
+                    regulator-name = "buck8";
+                    regulator-min-microvolt = <500000>;
+                    regulator-max-microvolt = <1300000>;
+                    regulator-always-on;
+                };
+                ldo1: ldo1 {
+                    regulator-name = "ldo1";
+                    rohm,ldo-range-high;
+                    regulator-min-microvolt = <800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                ldo2: ldo2 {
+                    regulator-name = "ldo2";
+                    regulator-min-microvolt = <800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                ldo3: ldo3 {
+                    regulator-name = "ldo3";
+                    regulator-min-microvolt = <800000>;
+                    regulator-max-microvolt = <3300000>;
+                    regulator-always-on;
+                };
+                ldo4: ldo4 {
+                    regulator-name = "ldo4";
+                    regulator-min-microvolt = <650000>;
+                    regulator-max-microvolt = <1750000>;
+                    regulator-always-on;
+                };
+            };
+        };
+    };
Signature · 1 line
2.55.0
#12 lore raw

Re: [PATCH v2 04/10] dt-bindings: mfd: ROHM BD73800 PMIC

Quoted 24 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4 LDOs. There is also an ADC and operation amplifier intended for current / temperature measurement and accumulation. RTC and 32.768 kHz clock gate are also included. The PMIC can be customized via OTP and it has options for operating as a main PMIC in multi-PMIC installation. Some of the pins can also be used for GPO or GPI (including interrupt support).

There are also ROHM BD71851 and BD71885 PMICs out there. These are, from the SW-perspective, similar to the BD73800. There is only some different default values and OTP settings. The driver should be able to handle them just fine.

---
Revision history:
v1 => v2:
- Reference commonly used ROHM bindings from a common binding file
- Simplify compatible list
- Move relevant comments to description so they can be shown in generated human-readable doc.
- Allow other clock-output-names besides "bd73800-32k-out"

Quoted 5 lines
---
 .../bindings/mfd/rohm,bd73800-pmic.yaml       | 218 ++++++++++++++++++
 1 file changed, 218 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.yaml

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck1: False schema does not allow {'regulator-name': ['buck1'], 'regulator-min-microvolt': [[800000]], 'regulator-max-microvolt': [[2000000]], 'regulator-always-on': True, 'regulator-ramp-delay': 1250, 'rohm,dvs-run-voltage': 1150000, 'rohm,dvs-suspend-voltage': 950000}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck2: False schema does not allow {'regulator-name': ['buck2'], 'regulator-min-microvolt': [[800000]], 'regulator-max-microvolt': [[2000000]], 'regulator-always-on': True, 'regulator-ramp-delay': 1250, 'rohm,dvs-run-voltage': 1150000, 'rohm,dvs-suspend-voltage': 950000}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck3: False schema does not allow {'regulator-name': ['buck3'], 'regulator-min-microvolt': [[1200000]], 'regulator-max-microvolt': [[2700000]], 'rohm,dvs-run-voltage': 1150000, 'rohm,dvs-idle-voltage': 1100000, 'rohm,dvs-suspend-voltage': 950000, 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck4: False schema does not allow {'regulator-name': ['buck4'], 'regulator-min-microvolt': [[1100000]], 'regulator-max-microvolt': [[1850000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck5: False schema does not allow {'regulator-name': ['buck5'], 'regulator-min-microvolt': [[1800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck6: False schema does not allow {'regulator-name': ['buck6'], 'regulator-min-microvolt': [[1800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck7: False schema does not allow {'regulator-name': ['buck7'], 'regulator-min-microvolt': [[1800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:buck8: False schema does not allow {'regulator-name': ['buck8'], 'regulator-min-microvolt': [[500000]], 'regulator-max-microvolt': [[1300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:ldo1: False schema does not allow {'regulator-name': ['ldo1'], 'rohm,ldo-range-high': True, 'regulator-min-microvolt': [[800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:ldo2: False schema does not allow {'regulator-name': ['ldo2'], 'regulator-min-microvolt': [[800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:ldo3: False schema does not allow {'regulator-name': ['ldo3'], 'regulator-min-microvolt': [[800000]], 'regulator-max-microvolt': [[3300000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd73800-pmic.example.dtb: pmic@4b (rohm,bd73800): regulators:ldo4: False schema does not allow {'regulator-name': ['ldo4'], 'regulator-min-microvolt': [[650000]], 'regulator-max-microvolt': [[1750000]], 'regulator-always-on': True}
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd73800-pmic.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/74468853a2c82091dfcdb2193c4eaa67f6191e05.1785838585.git.mazziesaccount@gmail.com

The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

#13 lore raw

PATCH v2 5/10 mfd: Support for ROHM BD73800 PMIC core

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The BD73800 integrates regulators, ADC (intended for accumulating current / voltage / power values), a real-time clock (RTC), clock gate and GPIOs.

Add core support for ROHM BD73800 Power Management IC.

---
Revision history:
v1 => v2:
- styling
- update copyright years

---
 drivers/mfd/Kconfig              |  15 +-
 drivers/mfd/rohm-bd71828.c       | 147 ++++++++++++++-
 include/linux/mfd/rohm-bd73800.h | 307 +++++++++++++++++++++++++++++++
 include/linux/mfd/rohm-generic.h |   1 +
 4 files changed, 462 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/mfd/rohm-bd73800.h
drivers/mfd/Kconfig +9 -6
index 763ce6a34782..c5e9032eb9de 100644
@@ -2222,7 +2222,7 @@ config MFD_ROHM_BD718XX
 	  and emergency shut down as well as 32,768KHz clock output.
 
 config MFD_ROHM_BD71828
-	tristate "ROHM BD718[15/28/79], BD72720 and BD73900 PMICs"
+	tristate "ROHM BD718[15/28/79], BD72720 and BD73[8/9]00 PMICs"
 	depends on I2C=y
 	depends on OF
 	select REGMAP_I2C
@@ -2230,14 +2230,17 @@ config MFD_ROHM_BD71828
 	select MFD_CORE
 	help
 	  Select this option to get support for the ROHM BD71815, BD71828,
-	  BD71879, BD72720 and BD73900 Power Management ICs (PMICs). These are
-	  single-chip Power Management ICs (PMIC), mainly for battery-powered
-	  portable devices.
+	  BD71879, BD72720, BD73800 and BD73900 Power Management ICs (PMICs).
+	  These are single-chip Power Management ICs (PMIC), mainly for
+	  battery-powered portable devices.
 	  The BD71815 has 5 bucks, 7 LDOs, and a boost for driving LEDs.
 	  The BD718[28/79] have 7 buck converters and 7 LDOs.
 	  The BD72720 and the BD73900 have 10 bucks and 11 LDOs.
-	  All ICs provide a single-cell linear charger, a Coulomb counter,
-	  a Real-Time Clock (RTC), GPIOs and a 32.768 kHz clock gate.
+	  All the above ICs provide a single-cell linear charger, and a Coulomb
+	  counter.
+	  The BD73800 has 8 bucks, 4 LDOs and ADC for power/current
+	  accumulation but no charging logic. All these PMICs integrate also a
+	  Real-Time Clock (RTC), GPIOs and a 32.768 kHz clock gate.
 
 config MFD_ROHM_BD957XMUF
 	tristate "ROHM BD9576MUF and BD9573MUF Power Management ICs"
drivers/mfd/rohm-bd71828.c +145 -2

213 lines not on this page · raw message

include/linux/mfd/rohm-bd73800.h new file +307 -0

307 lines not on this page · raw message

include/linux/mfd/rohm-generic.h +1 -0
index 0a284919a6c3..3ec87428ee97 100644
@@ -17,6 +17,7 @@ enum rohm_chip_type {
 	ROHM_CHIP_TYPE_BD71837,
 	ROHM_CHIP_TYPE_BD71847,
 	ROHM_CHIP_TYPE_BD72720,
+	ROHM_CHIP_TYPE_BD73800,
 	ROHM_CHIP_TYPE_BD96801,
 	ROHM_CHIP_TYPE_BD96802,
 	ROHM_CHIP_TYPE_BD96805,
Signature · 1 line
2.55.0
maintainer
#14 lore raw

Re: [PATCH v2 05/10] mfd: Support for ROHM BD73800 PMIC core

Quoted 14 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The BD73800 integrates regulators, ADC (intended for accumulating current / voltage / power values), a real-time clock (RTC), clock gate and GPIOs.

Add core support for ROHM BD73800 Power Management IC.

---
Revision history:
v1 => v2:
- styling
- update copyright years

Quoted 7 lines
---
 drivers/mfd/Kconfig              |  15 +-
 drivers/mfd/rohm-bd71828.c       | 147 ++++++++++++++-
 include/linux/mfd/rohm-bd73800.h | 307 +++++++++++++++++++++++++++++++
 include/linux/mfd/rohm-generic.h |   1 +
 4 files changed, 462 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/mfd/rohm-bd73800.h

Looks okay to me now.

Doesn't apply though, so will need a rebase.

I'd plan to apply this after the next merge-window.

Signature · 1 line
Lee Jones
maintainer Applied
#15 lore raw

Re: (subset) [PATCH v2 05/10] mfd: Support for ROHM BD73800 PMIC core

In reply to Matti Vaittinen
Quoted 4 lines · Matti Vaittinen

The BD73800 integrates regulators, ADC (intended for accumulating current / voltage / power values), a real-time clock (RTC), clock gate and GPIOs.

Add core support for ROHM BD73800 Power Management IC.

Applied, thanks!

[05/10] mfd: Support for ROHM BD73800 PMIC core

        commit: 6f6ebfdd38126edc6cd3f1427ee261d57a83fff9

--
Lee Jones [李琼斯]

maintainer
#16 lore raw

Re: (subset) [PATCH v2 05/10] mfd: Support for ROHM BD73800 PMIC core

Quoted 10 lines · Lee Jones
Quoted 4 lines · Matti Vaittinen

The BD73800 integrates regulators, ADC (intended for accumulating current / voltage / power values), a real-time clock (RTC), clock gate and GPIOs.

Add core support for ROHM BD73800 Power Management IC.

Applied, thanks!

[05/10] mfd: Support for ROHM BD73800 PMIC core

        commit: 6f6ebfdd38126edc6cd3f1427ee261d57a83fff9

This is a tooling error - b4 picking up old versions.

Signature · 1 line
Lee Jones
#17 lore raw

PATCH v2 6/10 rtc: bd70528: Support RTC on ROHM BD73800

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

BD73800 contains similar RTC block as BD71828 and BD71815. Only the address offsets seem different. Support also BD73800 RTC using the rtc-bd70528.

---
Revision history:
v1 => :
- No changes

---
 drivers/rtc/rtc-bd70528.c | 8 ++++++++
 1 file changed, 8 insertions(+)
drivers/rtc/rtc-bd70528.c +8 -0
index 482810b61495..fd415e327ea6 100644
@@ -8,6 +8,7 @@
 #include <linux/mfd/rohm-bd71815.h>
 #include <linux/mfd/rohm-bd71828.h>
 #include <linux/mfd/rohm-bd72720.h>
+#include <linux/mfd/rohm-bd73800.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
@@ -284,6 +285,12 @@ static int bd70528_probe(struct platform_device *pdev)
 		bd_rtc->bd718xx_alm_block_start = BD72720_REG_RTC_ALM_START;
 		hour_reg = BD72720_REG_RTC_HOUR;
 		break;
+	case ROHM_CHIP_TYPE_BD73800:
+		bd_rtc->reg_time_start = BD73800_REG_RTC_START;
+		bd_rtc->bd718xx_alm_block_start = BD73800_REG_RTC_ALM_START;
+		hour_reg = BD73800_REG_RTC_HOUR;
+		break;
+
 	default:
 		dev_err(&pdev->dev, "Unknown chip\n");
 		return -ENOENT;
@@ -344,6 +351,7 @@ static const struct platform_device_id bd718x7_rtc_id[] = {
 	{ .name = "bd71828-rtc", .driver_data = ROHM_CHIP_TYPE_BD71828 },
 	{ .name = "bd71815-rtc", .driver_data = ROHM_CHIP_TYPE_BD71815 },
 	{ .name = "bd72720-rtc", .driver_data = ROHM_CHIP_TYPE_BD72720 },
+	{ .name = "bd73800-rtc", .driver_data = ROHM_CHIP_TYPE_BD73800 },
 	{ }
 };
 MODULE_DEVICE_TABLE(platform, bd718x7_rtc_id);
Signature · 1 line
2.55.0
#18 lore raw

PATCH v2 7/10 regulator: bd71828: Support ROHM BD73800

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4 LDOs. The PMIC has internal state-machine and it can support transitions to RUN, SUSPEND and IDLE states. The LDOs 1 and 3 have two different voltage range configurations that can be set at the manufacturing phase by OTP. By default driver assumes low voltage ranges to be used because the data-sheet indicates the higher voltage ranges to be an 'OTP option'. The high voltage range can be indicated via device-tree property.

---
Revision history:
v1 => v2:
- Simplified DT parsing as was suggested by Mark
- Fix buck5 vsel_mask

---
 drivers/regulator/Kconfig             |   4 +-
 drivers/regulator/bd71828-regulator.c | 558 +++++++++++++++++++++++++-
 2 files changed, 559 insertions(+), 3 deletions(-)
drivers/regulator/Kconfig +2 -2
index 89789ac7a786..13928af8cad4 100644
@@ -241,12 +241,12 @@ config REGULATOR_BD71815
 	  will be called bd71815-regulator.
 
 config REGULATOR_BD71828
-	tristate "ROHM BD71828, BD72720 and BD73900 Power Regulators"
+	tristate "ROHM BD71828, BD72720 and BD73[8/9]00 Power Regulators"
 	depends on MFD_ROHM_BD71828
 	select REGULATOR_ROHM
 	help
 	  This driver supports voltage regulators on ROHM BD71828,
-	  BD71879, BD72720 and BD73900 PMICs. This will enable
+	  BD71879, BD72720 and BD73[8/9]00 PMICs. This will enable
 	  support for the software controllable buck and LDO regulators.
 
 	  This driver can also be built as a module. If so, the module
drivers/regulator/bd71828-regulator.c +557 -1

612 lines not on this page · raw message

Signature · 1 line
2.55.0
maintainer Acked-by on v2 7/10
#19 lore raw

Re: [PATCH v2 07/10] regulator: bd71828: Support ROHM BD73800

Quoted 6 lines · Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4 LDOs. The PMIC has internal state-machine and it can support transitions to RUN, SUSPEND and IDLE states. The LDOs 1 and 3 have two different voltage range configurations that can be set at the manufacturing phase

#20 lore raw

PATCH v2 8/10 clk: bd718x7: Support ROHM BD73800

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 PMIC has a 32.768 kHz clock gate. Add support for controlling this clock.

NOTE: The CLKOUT pin can be muxed by an OTP option. On some OTP configurations the CLKOUT is not outputting the clk signal.

---
Revision history:
v1 => :
- No changes

---
 drivers/clk/clk-bd718x7.c | 8 ++++++++
 1 file changed, 8 insertions(+)
drivers/clk/clk-bd718x7.c +8 -0
index 1cae974e6d1d..2dc6b8e46f18 100644
@@ -21,6 +21,9 @@
 #define BD718XX_REG_OUT32K	0x2E
 /* BD72720 */
 #define BD72720_REG_OUT32K	0x9a
+/* BD73800 */
+#define BD73800_REG_OUT32K	0x50
+
 /*
  * BD71837, BD71847, and BD71828 all use bit [0] to clk output control
  */
@@ -123,6 +126,10 @@ static int bd71837_clk_probe(struct platform_device *pdev)
 		c->reg = BD72720_REG_OUT32K;
 		c->mask = CLK_OUT_EN_MASK;
 		break;
+	case ROHM_CHIP_TYPE_BD73800:
+		c->reg = BD73800_REG_OUT32K;
+		c->mask = CLK_OUT_EN_MASK;
+		break;
 	default:
 		dev_err(&pdev->dev, "Unknown clk chip\n");
 		return -EINVAL;
@@ -152,6 +159,7 @@ static const struct platform_device_id bd718x7_clk_id[] = {
 	{ "bd71828-clk", ROHM_CHIP_TYPE_BD71828 },
 	{ "bd71815-clk", ROHM_CHIP_TYPE_BD71815 },
 	{ "bd72720-clk", ROHM_CHIP_TYPE_BD72720 },
+	{ "bd73800-clk", ROHM_CHIP_TYPE_BD73800 },
 	{ },
 };
 MODULE_DEVICE_TABLE(platform, bd718x7_clk_id);
Signature · 1 line
2.55.0
#21 lore raw

PATCH v2 9/10 gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

The ROHM BD73800 PMIC has 4 pins (named GPIO1, CLKOUT, FAULT_B and EXTEN_OUT) which might have been set to operate as a GPI or GPO when OTP (One Time Programmable memory) is written at device manufacturing. Support the GPI/GPO use-case via GPIO framework.

The default OTP for these pins is to not use any of them as GPI or GPO. (The GPIO1 defaults as an ADC input regardless the naming). Hence the driver assumes none of these pins is a GPI/GPO unless explicitly pointed as GPI or GPO via device tree.

Furthermore, pin's direction can't be changed after OTP configuration is done. Also the default drive type for a GPO (CMOS / Open Drain) is set by the OTP configuration. The BD73800 has a set of undocumented test registers which should allow changing the drive type. Access to the test register area or the test registers aren't documented and so this driver does not support configuring the drive type even though it might be doable.

---
Revision history:
v1 => v2:
- Return -ENODEV when no GPIO pins are found
- Drop useless comment
- Use 'data' instead of 'g' as a name of the private data struct. Do so consistently (change also the 'bdgpio' to 'data').
- Use device_property_... instead of the fwnode_property_...
- fix fault_b pin property name (re-use existing name)

---
 drivers/gpio/Kconfig        |  11 ++
 drivers/gpio/Makefile       |   1 +
 drivers/gpio/gpio-bd73800.c | 227 ++++++++++++++++++++++++++++++++++++
 3 files changed, 239 insertions(+)
 create mode 100644 drivers/gpio/gpio-bd73800.c
drivers/gpio/Kconfig +11 -0
index 28cf6d2e83c2..09d87c3b756f 100644
@@ -1363,6 +1363,17 @@ config GPIO_BD72720
 	  be configured to GPO on the ROHM PMIC. The pin configuration is done
 	  on OTP at manufacturing.
 
+config GPIO_BD73800
+	tristate "ROHM BD73800 GPIO support"
+	depends on MFD_ROHM_BD71828
+	help
+	  Support for GPIOs on ROHM BD73800 PMIC. There can be up to 4
+	  GPI or GPO pins available on the PMIC in total. The purpose of
+	  the pins is decided at the device manufacturing by OTP
+	  configuration and can't be reconfigured later. Enable this
+	  if your PMIC has pins set as GPIs or GPOs and if you wish to
+	  control the pins via the GPIO framework.
+
 config GPIO_BD9571MWV
 	tristate "ROHM BD9571 GPIO support"
 	depends on MFD_BD9571MWV
drivers/gpio/Makefile +1 -0
index 4d0e900402fc..3041c06aa933 100644
@@ -45,6 +45,7 @@ obj-$(CONFIG_GPIO_BCM_XGS_IPROC)	+= gpio-xgs-iproc.o
 obj-$(CONFIG_GPIO_BD71815)		+= gpio-bd71815.o
 obj-$(CONFIG_GPIO_BD71828)		+= gpio-bd71828.o
 obj-$(CONFIG_GPIO_BD72720)		+= gpio-bd72720.o
+obj-$(CONFIG_GPIO_BD73800)		+= gpio-bd73800.o
 obj-$(CONFIG_GPIO_BD9571MWV)		+= gpio-bd9571mwv.o
 obj-$(CONFIG_GPIO_BLZP1600)		+= gpio-blzp1600.o
 obj-$(CONFIG_GPIO_BRCMSTB)		+= gpio-brcmstb.o
drivers/gpio/gpio-bd73800.c new file +227 -0

227 lines not on this page · raw message

Signature · 1 line
2.55.0
maintainer
#22 lore raw

Re: [PATCH v2 09/10] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

Hi Matti,

thanks for your patch!

Quoted 29 lines · Matti Vaittinen
drivers/gpio/gpio-bd73800.c new file +29 -0
+static int bd73800gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+       int ret, val;
+
+       /* Only pins configured as GPI via OTP can have their status read */
+       if (pin->state != BD73800_PIN_GPI) {
+               dev_dbg(data->dev, "pin %d (%x) not input. State %d\n", offset,
+                       pin->mask, pin->state);
+               return -EINVAL;
+       }
+
+       ret = regmap_read(data->regmap, BD73800_REG_INT_5_SRC, &val);
+       if (ret)
+               return ret;
+
+       return val & pin->mask;
+}
+
+static int bd73800gpo_set(struct gpio_chip *chip, unsigned int offset,
+                         int value)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+
+       if (pin->state != BD73800_PIN_GPO) {
+               dev_dbg(data->dev, "pin %d (%d) not output. State %d\n",
+                       offset, pin->mask, pin->state);

drivers/gpio/gpio-bd73800.c line 138

Quoted 10 lines
drivers/gpio/gpio-bd73800.c new file +10 -0
+
+               return -EINVAL;
+       }
+
+       if (value)
+               return regmap_set_bits(data->regmap, BD73800_REG_GPO_OUT,
+                                      pin->mask);
+
+       return regmap_clear_bits(data->regmap, BD73800_REG_GPO_OUT, pin->mask);
+}

These can probably be handled by the latest version of gpio-regmap helpers (the version in linux-next).

We now support both input-only and output-only in gpio-regmap.

Latest <linux/gpio/regmap.h>:

* @fixed_direction_mask:

 *                      (Optional) Bitmap representing the GPIO lines that
 *                      make use of the @fixed_direction_output list to
 *                      enforce direction of the GPIO. If this is NULL
 *                      and @fixed_direction_output is defined, ALL GPIOs
 *                      are assumed to be fixed direction (out or in).
 * @fixed_direction_output:
 *                      (Optional) Bitmap representing the fixed direction of
 *                      the GPIO lines. Useful when there are GPIO lines with a
 *                      fixed direction mixed together in the same register.

It seems you can set up the fixed_direction_output mask from OTP and just use the library, right?

Yours,
Linus Walleij

maintainer
#23 lore raw

Re: [PATCH v2 09/10] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

Quoted 51 lines · Linus Walleij

Hi Matti,

thanks for your patch!

Quoted 29 lines · Matti Vaittinen
drivers/gpio/gpio-bd73800.c new file +29 -0
+static int bd73800gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+       int ret, val;
+
+       /* Only pins configured as GPI via OTP can have their status read */
+       if (pin->state != BD73800_PIN_GPI) {
+               dev_dbg(data->dev, "pin %d (%x) not input. State %d\n", offset,
+                       pin->mask, pin->state);
+               return -EINVAL;
+       }
+
+       ret = regmap_read(data->regmap, BD73800_REG_INT_5_SRC, &val);
+       if (ret)
+               return ret;
+
+       return val & pin->mask;
+}
+
+static int bd73800gpo_set(struct gpio_chip *chip, unsigned int offset,
+                         int value)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+
+       if (pin->state != BD73800_PIN_GPO) {
+               dev_dbg(data->dev, "pin %d (%d) not output. State %d\n",
+                       offset, pin->mask, pin->state);

drivers/gpio/gpio-bd73800.c line 138

Quoted 10 lines
drivers/gpio/gpio-bd73800.c new file +10 -0
+
+               return -EINVAL;
+       }
+
+       if (value)
+               return regmap_set_bits(data->regmap, BD73800_REG_GPO_OUT,
+                                      pin->mask);
+
+       return regmap_clear_bits(data->regmap, BD73800_REG_GPO_OUT, pin->mask);
+}

These can probably be handled by the latest version of gpio-regmap helpers (the version in linux-next).

Quoted 1 line

We now support both input-only and output-only in gpio-regmap.

Allright, I'll take a look at the gpio-regmap again. Thanks for letting me know ...

Quoted 14 lines

Latest <linux/gpio/regmap.h>:

* @fixed_direction_mask:

  *                      (Optional) Bitmap representing the GPIO lines that
  *                      make use of the @fixed_direction_output list to
  *                      enforce direction of the GPIO. If this is NULL
  *                      and @fixed_direction_output is defined, ALL GPIOs
  *                      are assumed to be fixed direction (out or in).
  * @fixed_direction_output:
  *                      (Optional) Bitmap representing the fixed direction of
  *                      the GPIO lines. Useful when there are GPIO lines with a
  *                      fixed direction mixed together in the same register.
Quoted 2 lines

It seems you can set up the fixed_direction_output mask from OTP and just use the library, right?

... and thanks for going the extra mile and giving me this pointer. Helps a lot! :) I wish all reviewers had the time to give this specific suggestions - although, I understand this is not always feasible with the amount of reviews/tasks to handle.

Yours,
-- Matti

Signature · 5 lines
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~
maintainer
#24 lore raw

Re: [PATCH v2 09/10] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

In reply to Linus Walleij
Quoted 66 lines · Linus Walleij

Hi Matti,

thanks for your patch!

Quoted 29 lines · Matti Vaittinen
drivers/gpio/gpio-bd73800.c new file +29 -0
+static int bd73800gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+       int ret, val;
+
+       /* Only pins configured as GPI via OTP can have their status read */
+       if (pin->state != BD73800_PIN_GPI) {
+               dev_dbg(data->dev, "pin %d (%x) not input. State %d\n", offset,
+                       pin->mask, pin->state);
+               return -EINVAL;
+       }
+
+       ret = regmap_read(data->regmap, BD73800_REG_INT_5_SRC, &val);
+       if (ret)
+               return ret;
+
+       return val & pin->mask;
+}
+
+static int bd73800gpo_set(struct gpio_chip *chip, unsigned int offset,
+                         int value)
+{
+       struct bd73800_gpio *data = gpiochip_get_data(chip);
+       struct bd73800_gpio_pin_cfg *pin = &data->pin[offset];
+
+       if (pin->state != BD73800_PIN_GPO) {
+               dev_dbg(data->dev, "pin %d (%d) not output. State %d\n",
+                       offset, pin->mask, pin->state);

drivers/gpio/gpio-bd73800.c line 138

Quoted 10 lines
drivers/gpio/gpio-bd73800.c new file +10 -0
+
+               return -EINVAL;
+       }
+
+       if (value)
+               return regmap_set_bits(data->regmap, BD73800_REG_GPO_OUT,
+                                      pin->mask);
+
+       return regmap_clear_bits(data->regmap, BD73800_REG_GPO_OUT, pin->mask);
+}

These can probably be handled by the latest version of gpio-regmap helpers (the version in linux-next).

We now support both input-only and output-only in gpio-regmap.

Latest <linux/gpio/regmap.h>:

* @fixed_direction_mask:

  *                      (Optional) Bitmap representing the GPIO lines that
  *                      make use of the @fixed_direction_output list to
  *                      enforce direction of the GPIO. If this is NULL
  *                      and @fixed_direction_output is defined, ALL GPIOs
  *                      are assumed to be fixed direction (out or in).
  * @fixed_direction_output:
  *                      (Optional) Bitmap representing the fixed direction of
  *                      the GPIO lines. Useful when there are GPIO lines with a
  *                      fixed direction mixed together in the same register.
Quoted 2 lines

It seems you can set up the fixed_direction_output mask from OTP and just use the library, right?

The BD73800 uses different registers for 'out' and 'in'. So there aren't really "GPIO lines with a fixed direction mixed together in the same register".

I, however, see some good stuff being in the linux-next! Finally a bit of flexibility in a form of callbacks a driver can register is getting in. So I am somewhat hopeful the usability of gpio-regmap will finally increase.

I think the BD73800 can indeed use the gpio-regmap, by keeping the pin direction information in private data and adding a custom xlate, which errors out if get is requested for output pin, or set is requested for input. I am not sure how much of an improvement it is compared to the patch v2, but I'll give it a shot :) I believe the new -rc1 isn't that far away, and hopefully the gpio-regmap -stuff from the next will be in it together with the regulator stuff bindings depended.

Thanks again for the pointer!

Yours,
-- Matti

Signature · 5 lines
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~
maintainer
#25 lore raw

Re: [PATCH v2 09/10] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

Quoted 1 line · Matti Vaittinen

On 07/08/2026 23:29, Linus Walleij wrote:

...

Quoted 9 lines
Quoted 7 lines

  * @fixed_direction_output:
  *                      (Optional) Bitmap representing the fixed direction of *                      the GPIO lines. Useful when there are GPIO lines with a *                      fixed direction mixed together in the same register.

It seems you can set up the fixed_direction_output mask from OTP and just use the library, right?

The BD73800 uses different registers for 'out' and 'in'. So there aren't really "GPIO lines with a fixed direction mixed together in the same register".

...

Quoted 1 line

I think the BD73800 can indeed use the gpio-regmap, by keeping the pin direction information in private data and adding a custom xlate, which errors out if get is requested for output pin, or set is requested for input. I am not sure how much of an improvement it is compared to the patch v2, but I'll give it a shot :) I believe the new -rc1 isn't that far away, and hopefully the gpio-regmap -stuff from the next will be in it together with the regulator stuff bindings depended.

Gah. Please, ignore the erroring-out part. I don't know where I picked the idea that the hardware would always return '0' when reading the GPO_OUT register. I think this might have been something I have experienced on a setup where the pin was _not_ set to GPO by OTP. Furthermore, the xlate will never get called if user tries to set value for a GPI pin.

Anyways, implementing xlate with op-check allows me to support this PMIC, even though the register to read for pin status depends on OTP.

So yes, v3 should be able to use gpio-regmap. I will probably delay sending it until v7.3-rc1 is out so I get (all?) dependencies in.

Yours,
-- Matti

Signature · 5 lines
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~
#26 lore raw

PATCH v2 10/10 MAINTAINERS: Add ROHM BD73800 PMIC files

In reply to Matti Vaittinen

From: Matti Vaittinen <[email protected]>

Add the undersigned as a maintainer for the ROHM BD73800 PMIC related files.

---
Revision history:
v1 => :
- No changes

---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)
MAINTAINERS +2 -0
index 716acfc3d7c1..0f1e2c2e1046 100644
@@ -23545,6 +23545,7 @@ F:	drivers/clk/clk-bd718x7.c
 F:	drivers/gpio/gpio-bd71815.c
 F:	drivers/gpio/gpio-bd71828.c
 F:	drivers/gpio/gpio-bd72720.c
+F:	drivers/gpio/gpio-bd73800.c
 F:	drivers/mfd/rohm-bd71828.c
 F:	drivers/mfd/rohm-bd718x7.c
 F:	drivers/mfd/rohm-bd9576.c
@@ -23562,6 +23563,7 @@ F:	include/linux/mfd/rohm-bd71815.h
 F:	include/linux/mfd/rohm-bd71828.h
 F:	include/linux/mfd/rohm-bd718x7.h
 F:	include/linux/mfd/rohm-bd72720.h
+F:	include/linux/mfd/rohm-bd73800.h
 F:	include/linux/mfd/rohm-bd957x.h
 F:	include/linux/mfd/rohm-bd96801.h
 F:	include/linux/mfd/rohm-bd96802.h
Signature · 1 line
2.55.0