Some Qualcomm platforms require a significant delay after powering off a
rail before it can be powered on again, especially for regulators that
depend on passive discharge.

The core regulator framework supports this via the 'regulator-off-on-delay-us'
property, but the RPMh regulator driver currently ignores it.

Add support for parsing this generic property from device tree and
populating the regulator descriptor. This allows board-specific DTS files
to specify required discharge delays for RPMh-controlled regulators.

Tested-on: Lenovo Yoga Slim 7x (Snapdragon X Elite)
Signed-off-by: Saikiran <bjsaikiran@gmail.com>
---
 drivers/regulator/qcom-rpmh-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
index 6e4cb2871fca..aafba61551b3 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -503,6 +503,9 @@ static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device *dev,
 	vreg->always_wait_for_ack = of_property_read_bool(node,
 						"qcom,always-wait-for-ack");
 
+	of_property_read_u32(node, "regulator-off-on-delay-us",
+			     &vreg->rdesc.off_on_delay);
+
 	vreg->rdesc.owner	= THIS_MODULE;
 	vreg->rdesc.type	= REGULATOR_VOLTAGE;
 	vreg->rdesc.ops		= vreg->hw_data->ops;
-- 
2.51.0

On Tue, Jan 27, 2026 at 10:57:57PM +0530, Saikiran wrote:

> Some Qualcomm platforms require a significant delay after powering off a
> rail before it can be powered on again, especially for regulators that
> depend on passive discharge.

> The core regulator framework supports this via the 'regulator-off-on-delay-us'
> property, but the RPMh regulator driver currently ignores it.

The core regulator framework does not support this, this is specifically
a property supported by the fixed voltage regulator.

> Add support for parsing this generic property from device tree and
> populating the regulator descriptor. This allows board-specific DTS files
> to specify required discharge delays for RPMh-controlled regulators.

This would at a minimum need the bindings for the regulators on the
affected platforms to be updated.  What exactly are we talking about in
terms of the actual configuration here, what goes wrong if we don't
leave the regulator powered off and how sure are we that this is
platform specific rather than regulator specific?  I'm guessing these
are LDOs?

Hi Mark,

(Apologies, our emails crossed, I sent v2 to fix the commit log format
before seeing this reply).

> The core regulator framework does not support this... specifically supported by fixed voltage regulator.

I see that "of_get_regulation_constraints()" in
drivers/regulator/of_regulator.c parses "regulator-off-on-delay-us".
Since qcom-rpmh-regulator uses of_regulator_match(), I will verify if
the core handles this automatically without needing manual parsing in
the driver. If it works via standard constraints, I will drop this
driver patch and only submit the DT Binding update.

> What exactly are we talking about in terms of the actual configuration here...

These are LDOs (LDO1, LDO3 and LDO7) powering camera sensors on the
Lenovo Yoga Slim 7x.
The issue is platform-specific: this board has large bulk capacitors
on the camera rails. When the LDO is disabled, the voltage decays very
slowly (passive discharge), taking some time (Still testing various
timings) to reach a safe reset level. If we re-enable the rail before
this discharge completes, the sensor experiences a brownout and fails
to initialize.

> This would at a minimum need the bindings for the regulators on the affected platforms to be updated.

Understood. I missed the binding update. I will prepare a patch to
update Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
to allow this property.

I will test the standard constraint path and report back.

Thanks & Regards,
Saikiran

On Tue, Jan 27, 2026 at 11:06 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Jan 27, 2026 at 10:57:57PM +0530, Saikiran wrote:
>
> > Some Qualcomm platforms require a significant delay after powering off a
> > rail before it can be powered on again, especially for regulators that
> > depend on passive discharge.
>
> > The core regulator framework supports this via the 'regulator-off-on-delay-us'
> > property, but the RPMh regulator driver currently ignores it.
>
> The core regulator framework does not support this, this is specifically
> a property supported by the fixed voltage regulator.
>
> > Add support for parsing this generic property from device tree and
> > populating the regulator descriptor. This allows board-specific DTS files
> > to specify required discharge delays for RPMh-controlled regulators.
>
> This would at a minimum need the bindings for the regulators on the
> affected platforms to be updated.  What exactly are we talking about in
> terms of the actual configuration here, what goes wrong if we don't
> leave the regulator powered off and how sure are we that this is
> platform specific rather than regulator specific?  I'm guessing these
> are LDOs?

On Tue, Jan 27, 2026 at 11:13:45PM +0530, Saikiran B wrote:

> > What exactly are we talking about in terms of the actual configuration here...

> These are LDOs (LDO1, LDO3 and LDO7) powering camera sensors on the
> Lenovo Yoga Slim 7x.
> The issue is platform-specific: this board has large bulk capacitors
> on the camera rails. When the LDO is disabled, the voltage decays very
> slowly (passive discharge), taking some time (Still testing various
> timings) to reach a safe reset level. If we re-enable the rail before
> this discharge completes, the sensor experiences a brownout and fails
> to initialize.

OK, that makes sense - please include this description in the commit
log.

> > This would at a minimum need the bindings for the regulators on the affected platforms to be updated.

> Understood. I missed the binding update. I will prepare a patch to
> update Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
> to allow this property.

Great, sounds good.