From: Sasha Finkelstein <fnkl.kernel@gmail.com>
Add bindings for exposing SPMI registers as NVMEM cells
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
---
.../devicetree/bindings/nvmem/spmi-nvmem.yaml | 54 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 55 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..d16b27128f97b5d38fb6ddb5109c70cda5e2ee15
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/spmi-nvmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic SPMI NVMEM
+
+description: Exports a series of SPMI registers as NVMEM cells
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,maverick-pmic
+ - apple,sera-pmic
+ - apple,stowe-pmic
+ - const: spmi-nvmem
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@f {
+ compatible = "apple,maverick-pmic", "spmi-nvmem";
+ reg = <0xf SPMI_USID>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ boot_stage: boot-stage@6001 {
+ reg = <0x6001 0x1>;
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 96b82704950184bd71623ff41fc4df31e4c7fe87..e7b2d0df81b387ba5398957131971588dc7b89dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2277,6 +2277,7 @@ F: Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
F: Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
F: Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
F: Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
+F: Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
F: Documentation/devicetree/bindings/pci/apple,pcie.yaml
F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
F: Documentation/devicetree/bindings/power/apple*
--
2.49.0On Thu, Apr 17, 2025 at 10:14:49PM +0200, Sasha Finkelstein wrote:
> Add bindings for exposing SPMI registers as NVMEM cells
>
> Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
> ---
> .../devicetree/bindings/nvmem/spmi-nvmem.yaml | 54 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..d16b27128f97b5d38fb6ddb5109c70cda5e2ee15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/spmi-nvmem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic SPMI NVMEM
What makes this generic?
A generic driver is great, but "generic" or "simple" bindings are
generally a mistake.
> +
> +description: Exports a series of SPMI registers as NVMEM cells
> +
> +maintainers:
> + - Sasha Finkelstein <fnkl.kernel@gmail.com>
> +
> +allOf:
> + - $ref: nvmem.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - apple,maverick-pmic
> + - apple,sera-pmic
> + - apple,stowe-pmic
> + - const: spmi-nvmem
What happens when there's some other feature of the PMIC exposed that's
not nvmem?
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/spmi/spmi.h>
> +
> + pmic@f {
> + compatible = "apple,maverick-pmic", "spmi-nvmem";
> + reg = <0xf SPMI_USID>;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + boot_stage: boot-stage@6001 {
> + reg = <0x6001 0x1>;
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96b82704950184bd71623ff41fc4df31e4c7fe87..e7b2d0df81b387ba5398957131971588dc7b89dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2277,6 +2277,7 @@ F: Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> F: Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> F: Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
> F: Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
> +F: Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> F: Documentation/devicetree/bindings/pci/apple,pcie.yaml
> F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
> F: Documentation/devicetree/bindings/power/apple*
>
> --
> 2.49.0
>
On Tue, 22 Apr 2025 at 15:36, Rob Herring <robh@kernel.org> wrote: > > +title: Generic SPMI NVMEM > > What makes this generic? > > A generic driver is great, but "generic" or "simple" bindings are > generally a mistake. There is nothing apple-specific in that driver, just re-exporting several registers as cells. If you think that it is a mistake, I can rename it to apple-pmic, or something similar. > > + - const: spmi-nvmem > > What happens when there's some other feature of the PMIC exposed that's > not nvmem? If you have a PMIC that needs more features exposed, then you'd have to use a different driver. Or am i not understanding the question correctly?
Sasha Finkelstein 於 2025/4/22 夜晚9:44 寫道: > On Tue, 22 Apr 2025 at 15:36, Rob Herring <robh@kernel.org> wrote: >>> +title: Generic SPMI NVMEM >> What makes this generic? >> >> A generic driver is great, but "generic" or "simple" bindings are >> generally a mistake. > There is nothing apple-specific in that driver, just re-exporting > several registers as cells. If you think that it is a mistake, I can > rename it to apple-pmic, or something similar. > >>> + - const: spmi-nvmem >> What happens when there's some other feature of the PMIC exposed that's >> not nvmem? > If you have a PMIC that needs more features exposed, then you'd have to > use a different driver. Or am i not understanding the question correctly? I think the problem is what happens if more functionalities needed to be exposed from the M1 SoC's PMIC. (right now I do not believe anything else is needed from it) It would be multiple drivers. A simple-mfd-spmi driver (like drivers/mfd/simple-mfd-i2c.c but SPMI) that exports a regmap and a generic driver that reexports regmap (any regmap, not necessarily SPMI) as nvmem cells, plus extra drivers that uses the regmap exposed by the mfd driver for extra functionalities. To make this submission more generic and extensible, what would be submitted should be a simple-mfd-spmi driver and a generic regmap nvmem driver. For specific examples, see below: The PMICs from dialog semiconductor on older Apple SoCs definitely needs such functionalities. On Apple A11 SoC there is a RTC clock device on the PMIC and the SMC on there does not have RTC functionalities. To make the RTC clock work there a driver would read a counter that could count a maximum of 194 days from the SPMI PMIC, and then access the PMIC nvmem cells that held the rest of the time. In this case these drivers are needed: (1) simple-mfd-spmi (2) rtc driver (3) generic regmap nvmem driver. On Apple A7-A10X SoC a similar PMIC also exist, but is over I2C instead of SPMI, those devices do not have a SMC. To make the rtc clock work there three drivers are needed: (1) simple-mfd-i2c (already exists) (2) rtc driver (same one as above) (3) generic regmap nvmem driver The PMICs on A7-A10X SoCs are also known to have WLED output for backlight, shutdown controls and some sort of pinctrl needed for things like bluetooth. In both cases a combination of (1) and (3) is more generic and applies to more than one bus types, and allow extra functionalities other than nvmem to be added. > Nick Chan
On Tue, Apr 22, 2025 at 11:59 PM Nick Chan <towinchenmi@gmail.com> wrote: > > > Sasha Finkelstein 於 2025/4/22 夜晚9:44 寫道: > > On Tue, 22 Apr 2025 at 15:36, Rob Herring <robh@kernel.org> wrote: > >>> +title: Generic SPMI NVMEM > >> What makes this generic? > >> > >> A generic driver is great, but "generic" or "simple" bindings are > >> generally a mistake. > > There is nothing apple-specific in that driver, just re-exporting > > several registers as cells. If you think that it is a mistake, I can > > rename it to apple-pmic, or something similar. Like I said, a generic *driver* is great! I'm all for them. We should have more of them! Generic bindings on the other hand are generally a mistake. The problem is whether a generic driver works for you or not can evolve in either direction. You add more things like described below and then a generic driver doesn't work. > >>> + - const: spmi-nvmem > >> What happens when there's some other feature of the PMIC exposed that's > >> not nvmem? > > If you have a PMIC that needs more features exposed, then you'd have to > > use a different driver. Or am i not understanding the question correctly? > I think the problem is what happens if more functionalities needed to be exposed from the M1 SoC's > PMIC. (right now I do not believe anything else is needed from it) Yes, and you can add to the binding then, but you are stuck with what you define now. > It would be multiple drivers. A simple-mfd-spmi driver (like drivers/mfd/simple-mfd-i2c.c > but SPMI) that exports a regmap and a generic driver that reexports regmap (any regmap, > not necessarily SPMI) as nvmem cells, plus extra drivers that uses the regmap exposed by > the mfd driver for extra functionalities. > > To make this submission more generic and extensible, what would be submitted should be a > simple-mfd-spmi driver and a generic regmap nvmem driver. For specific examples, see below: It is not an MFD currently, so you don't need an MFD driver. As I said, that can evolve. Drivers are bus specific, so you can't have a generic regmap driver. There's only 4 nvmem drivers using regmap anyways. qcom-spmi-sdam is one of them, and maybe one driver could handle that and Apple. > The PMICs from dialog semiconductor on older Apple SoCs definitely needs such functionalities. > > On Apple A11 SoC there is a RTC clock device on the PMIC and the SMC on there does not have > RTC functionalities. To make the RTC clock work there a driver would read a counter that could > count a maximum of 194 days from the SPMI PMIC, and then access the PMIC nvmem cells that > held the rest of the time. In this case these drivers are needed: > > (1) simple-mfd-spmi (2) rtc driver (3) generic regmap nvmem driver. > > On Apple A7-A10X SoC a similar PMIC also exist, but is over I2C instead of SPMI, those devices do not > have a SMC. To make the rtc clock work there three drivers are needed: > > (1) simple-mfd-i2c (already exists) (2) rtc driver (same one as above) (3) generic regmap nvmem driver It all sounds a bit different from what's there on the M series, so perhaps better not to mix the 2 just because it is all apple. The A series stuff might have more in common with existing Dialog PMICs. Rob
> > >> What makes this generic? > > >> > > >> A generic driver is great, but "generic" or "simple" bindings are > > >> generally a mistake. > > > There is nothing apple-specific in that driver, just re-exporting > > > several registers as cells. If you think that it is a mistake, I can > > > rename it to apple-pmic, or something similar. > > Like I said, a generic *driver* is great! I'm all for them. We should > have more of them! Generic bindings on the other hand are generally a > mistake. The problem is whether a generic driver works for you or not > can evolve in either direction. You add more things like described > below and then a generic driver doesn't work. It sounds like the path of least resistance here is then: 1. rename the bindings to be apple m1+ (at least for now) 2. keep the driver as-is (no mfd, etc - at least for now) 3. land just that (at least for now) Evolving the driver to share with not-Apple, or evolving the bindings+driver to share with pre-M1, can happen in future series if/when somebody wants to do that work. Is this a fair understanding of the situation?
On Wed, 23 Apr 2025 at 17:46, Alyssa Rosenzweig <alyssa@rosenzweig.io> wrote: > It sounds like the path of least resistance here is then: > > 1. rename the bindings to be apple m1+ (at least for now) > 2. keep the driver as-is (no mfd, etc - at least for now) > 3. land just that (at least for now) > > Evolving the driver to share with not-Apple, or evolving the > bindings+driver to share with pre-M1, can happen in future series > if/when somebody wants to do that work. That is precisely my plan for v3, which I intend to send soon-ish.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Le Thu , Apr 17, 2025 at 10:14:49PM +0200, Sasha Finkelstein via B4 Relay a écrit :
> From: Sasha Finkelstein <fnkl.kernel@gmail.com>
>
> Add bindings for exposing SPMI registers as NVMEM cells
>
> Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
> ---
> .../devicetree/bindings/nvmem/spmi-nvmem.yaml | 54 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..d16b27128f97b5d38fb6ddb5109c70cda5e2ee15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/spmi-nvmem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic SPMI NVMEM
> +
> +description: Exports a series of SPMI registers as NVMEM cells
> +
> +maintainers:
> + - Sasha Finkelstein <fnkl.kernel@gmail.com>
> +
> +allOf:
> + - $ref: nvmem.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - apple,maverick-pmic
> + - apple,sera-pmic
> + - apple,stowe-pmic
> + - const: spmi-nvmem
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/spmi/spmi.h>
> +
> + pmic@f {
> + compatible = "apple,maverick-pmic", "spmi-nvmem";
> + reg = <0xf SPMI_USID>;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + boot_stage: boot-stage@6001 {
> + reg = <0x6001 0x1>;
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96b82704950184bd71623ff41fc4df31e4c7fe87..e7b2d0df81b387ba5398957131971588dc7b89dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2277,6 +2277,7 @@ F: Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> F: Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> F: Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
> F: Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
> +F: Documentation/devicetree/bindings/nvmem/spmi-nvmem.yaml
> F: Documentation/devicetree/bindings/pci/apple,pcie.yaml
> F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
> F: Documentation/devicetree/bindings/power/apple*
>
> --
> 2.49.0
>
>
© 2016 - 2025 Red Hat, Inc.