Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls

[Max Krummenacher]

Hi all

On Thu, Jun 16, 2022 at 2:51 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Thu, Jun 9, 2022 at 5:10 PM Max Krummenacher <max.oss.09@xxxxxxxxx> wrote:
>
> > This series adds a PM domain provider driver which enables/disables
> > a regulator to control its power state.
>
> Actually, we did this on the U8500 in 2011.
>
> IIRC this led to problems because we had to invent "atomic regulators"
> because regulators use kernel abstractions that assume slowpath
> (process context) and power domains does not, i.e. they execute in
> fastpath, such as an interrupt handler.
>
> The atomic regulator was a subset of regulator that only handled
> regulators that would result in something like an atomic register write.
>
> In the end it was not worth trying to upstream this approach, and
> as I remember it, Ulf Hansson intended to let the power domains poke
> these registers directly, which was easier. (It's on Ulfs TODO list to
> actually implement this, hehe.)
>
> Yours,
> Linus Walleij

Thanks for all the feedback.

The approach taken with the patchset seems to be architecturally wrong
and as Linus pointed out has additionally the flaw that the regulator
would need to be controllable in atomic context which depending on
the regulator driver / configuration may not be fulfilled.

So our plan is to explicitly handle a (shared) regulator in every
driver involved, adding that regulator capability for drivers not
already having one.


The question which remains is on how one would model functionality
which by itself does not need a driver but would need regulator
support to switch its supply on in run state and off in suspend
states and poweroff, like for example a simple level shifter.
Any suggestions on this topic? Thanks.

Cheers
Max