Re: [PATCH v5 3/4] regulator: qcom-rpmh: readback voltage/bypass/mode/status set during bootup
From: Kamal Wadhwa
Date: Thu Jul 30 2026 - 04:25:09 EST
On Thu, Jul 30, 2026 at 12:11:26AM +0100, Mark Brown wrote:
> On Thu, Jul 30, 2026 at 03:28:39AM +0530, Kamal Wadhwa wrote:
> > On Wed, Jul 29, 2026 at 09:04:47PM +0100, Mark Brown wrote:
> > > On Thu, Jul 30, 2026 at 01:11:36AM +0530, Kamal Wadhwa wrote:
>
> > > > I can drop it. But I seek your guidance on how should i implement logic
> > > > to HOLD the enable/voltage/mode for the regulators which are turned ON by
> > > > bootloader.
>
> > > You could cache the values currently written to the control interface?
>
> > We can cache it, but i was planning to add change in core,
> > which will require get_status() or something similar i think.
>
> I would have thought we could use the currently configured state here.
>
> > > > Besides this, since the sync_state() cannot be used.. i was thinking if holding
> > > > the voltage/mode/enable till regulator_late_cleanup(). is that ok?
>
> > > Consider what happens if something really needs a voltage raising to
> > > enumerate - if you ignore it then the hardware might be in for a bad
> > > time.
>
> > May be we can allow the up-ing of voltage/mode to go through? but cache the
> > lowering requests for voltage/mode and apply them in regulator_late_cleanup()
> > so we are sure that there is more then sufficient power during this sensitive
> > phase. will that work?
>
> It's certainly much less likely to be an issue. There's some similar
> issues around enables for exclusive regulatorss though, and I wouldn't
> discount lower voltages being an issue (off the top of my head I've got
> a feeling MMC needs to lower voltages to up clock rates but I could be
> misremembering the use case). Whole thing is a massive can of worms,
> that's why it's not been addressed :/
Do you think allowing this behaviour via a new regulator DT prop like
`regulator-hold-on-boot` to allow per-regulator control.. rather then applying to
all the regulators which are ON at boot.. may help address some of those concerns?
IMHO, from the design point of view it has to be either allowing all the requests
OR allow only the up-ing of the voltage/mode till all clients are up, may be needed.
>
> > > Will the bootloader be running at the same time as the kernel, I really
> > > mean "by something else" rather than "autonomously" - usually that's the
> > > device itself (eg, reporting that a regulator was shut down due to over
> > > current) but it could be something else I guess.
>
> > Ok, so is there something similar to get_status() that i can use to pass on the
> > info to core (from the driver) that regulator state was ON at bootloader stage?
>
> is_enabled() would be the usual thing.
thanks, i'll use that that then.