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
