Re: [PATCH 10/11] regulator: db8500: Add power domain regulators

On Thu, Aug 20, 2026 at 12:24 PM Ulf Hansson
<[email protected]> wrote:
> On Wed, Aug 19, 2026 at 3:30 PM Linus Walleij <[email protected]> wrote:

> > > > @@ -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.
>
> So with I2C devices you are not referring to the I2C controllers, right?
>
> Are you saying that these external I2C devices consume the same
> regulator as the power-domain DOMAIN_VAPE uses?
>
> I thought these types of external devices in general use a different
> voltage range. Moreover, do note that DOMAIN_VAPE also has
> corresponding OPPs (performance states) that change the voltage level
> based on the requested OPP. I am not sure an external I2C would be
> able to cope with that.

I did the mistake to trust the device trees :(

It seems all the device trees are buggy, because components
that should be connected to VSMPS2 from the AB8500 PMIC
have been instead connected to the DB8500 VSMPS2 power
domain... The one instance of VARM being used outside of the
SoC was a bug as well.

OK I go and fix this, worst case I add a fixed regulator for it,
it's an "always on except during sleep" type of thing.

We should be able to drop this patch entirely!

Yours,
Linus Walleij