[PATCH 10/11] regulator: db8500: Add power domain regulators
Linus Walleij
linusw at kernel.org
Wed Aug 19 06:30:29 PDT 2026
On Wed, Jul 8, 2026 at 5:53 PM Ulf Hansson <ulf.hansson at oss.qualcomm.com> wrote:
> On Thu, Jun 18, 2026 at 7:01 AM Linus Walleij <linusw at kernel.org> wrote:
> >
> > Add a DB8500 regulator driver for the VAPE and VSMPS2 compatibility nodes.
> >
> > Back the regulator enable state with the corresponding power domains.
> >
> > This is done for off-chip consumers: the corresponding voltage rails are
> > routed out so they are used for powering different peripherals using
> > these voltages as supplies.
> >
> > Assisted-by: Codex:gpt-5-5
> > Signed-off-by: Linus Walleij <linusw at kernel.org>
(...)
> > @@ -673,6 +673,7 @@ db8500-prcmu-regulators {
> > // DB8500_REGULATOR_VAPE
> > db8500_vape_reg: db8500_vape {
> > regulator-always-on;
> > + power-domains = <&pm_domains DOMAIN_VAPE>;
>
> Hmm, isn't this the other way around? The power-domains node should
> have a regulator supply?
They probably have that, but that is not what this is about,
it's the other way around.
> We may even consider to skip to model the regulator altogether and
> make the power domain operate directly on the prcmu instead.
That is what the series tries to do, as a whole. Sorry if that was unclear...
What we do in this patch is to deal with the fact that two of the power
domains, when enabled, also turn on two external power rails outside
of the SoC.
Since external components such as I2C devices cannot really be
claimed as "being inside a power domain" they take a regulator.
This is based on my understanding that power domains is an
SoC-internal concept only, so there is a clear boundary if something
outside of the SoC starts to use such an externalized power rail.
All this regulator does is to make sure the corresponding power domain
is enabled when the regulator is enabled.
I will repost all the patches once v7.3-rc1 is out.
Yours,
Linus Walleij
More information about the linux-arm-kernel
mailing list