Re: [PATCH v5 3/4] regulator: qcom-rpmh: readback voltage/bypass/mode/status set during bootup
From: Mark Brown
Date: Wed Jul 29 2026 - 19:17:29 EST
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 :/
> > 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.
Attachment:
signature.asc
Description: PGP signature