Message-ID: <CAL_JsqKwASbUtpO=wU-16v=y8S_wLyBxnFUmQqsE8GkzCz0hDg@mail.gmail.com>
Date: Wed, 23 Apr 2025 10:19:48 -0500
From: Rob Herring <robh@...nel.org>
To: Nick Chan <towinchenmi@...il.com>
Cc: Sasha Finkelstein <fnkl.kernel@...il.com>, Sven Peter <sven@...npeter.dev>, 
	Janne Grunau <j@...nau.net>, Alyssa Rosenzweig <alyssa@...enzweig.io>, Neal Gompa <neal@...pa.dev>, 
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, asahi@...ts.linux.dev, 
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: spmi: Add generic SPMI NVMEM

On Tue, Apr 22, 2025 at 11:59 PM Nick Chan <towinchenmi@...il.com> wrote:
>
>
> Sasha Finkelstein 於 2025/4/22 夜晚9:44 寫道:
> > On Tue, 22 Apr 2025 at 15:36, Rob Herring <robh@...nel.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

Powered by blists - more mailing lists