[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEHkU3Wya0nRhaBDisAQBm5kf=2YcdJYzz2jKiL___mZQzL_Sw@mail.gmail.com>
Date: Thu, 23 Jun 2022 18:14:36 +0200
From: Max Krummenacher <max.oss.09@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Max Krummenacher <max.krummenacher@...adex.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Linux PM list <linux-pm@...r.kernel.org>,
Francesco Dolcini <francesco.dolcini@...adex.com>,
Mark Brown <broonie@...nel.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
Andrejs Cainikovs <andrejs.cainikovs@...adex.com>,
Biju Das <biju.das.jz@...renesas.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Fabio Estevam <festevam@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Marcel Ziswiler <marcel.ziswiler@...adex.com>,
NXP Linux Team <linux-imx@....com>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Rob Herring <robh+dt@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Shawn Guo <shawnguo@...nel.org>, Vinod Koul <vkoul@...nel.org>,
Will Deacon <will@...nel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider
which controls
Hi all
On Thu, Jun 16, 2022 at 2:51 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Thu, Jun 9, 2022 at 5:10 PM Max Krummenacher <max.oss.09@...il.com> 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
Powered by blists - more mailing lists