[PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Saikiran]

This patch adds support for the generic `regulator-off-on-delay-us` property
to the Qualcomm RPMh regulator driver.

The core regulator framework supports enforcing a physical off-time via
standard properties, but the `qcom-rpmh-regulator` driver currently ignores
them. This prevents boards with slow-discharging rails from enforcing safe
power-cycling constraints.

Motivation / Test Result:
On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
rely on passive discharge and require a significant off-time to drop below
brownout thresholds.

I have tested this patch on the Yoga Slim 7x. When the delay property is
present in the device tree, the regulator core correctly blocks re-enable
calls until the delay passes. This successfully fixes the camera brownout
issues and allows reliable sensor initialization during rapid power cycling.

I am submitting this driver support first to ensure the mechanism is available.
Once the consumer nodes (camera) for this board are upstream, we will apply
the specific delay values in the DTS.

Saikiran (1):
  regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Saikiran]

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

Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Saikiran B]

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?

Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Tue, Jan 27, 2026 at 10:57:56PM +0530, Saikiran wrote:
> This patch adds support for the generic `regulator-off-on-delay-us` property
> to the Qualcomm RPMh regulator driver.

Please don't send cover letters for single patches, if there is anything
that needs saying put it in the changelog of the patch or after the ---
if it's administrative stuff.  This reduces mail volume and ensures that 
any important information is recorded in the changelog rather than being
lost. 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH] regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[Saikiran]

This patch adds support for the generic `regulator-off-on-delay-us` property
to the Qualcomm RPMh regulator driver.

The core regulator framework supports enforcing a physical off-time via
standard properties, but the `qcom-rpmh-regulator` driver currently ignores
them. This prevents boards with slow-discharging rails from enforcing safe
power-cycling constraints.

Motivation / Test Result:
On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
rely on passive discharge and require a significant off-time to drop below
brownout thresholds.

I have tested this patch on the Yoga Slim 7x. When the delay property is
present in the device tree, the regulator core correctly blocks re-enable
calls until the delay passes. This successfully fixes the camera brownout
issues and allows reliable sensor initialization during rapid power cycling.

I am submitting this driver support first to ensure the mechanism is available.
Once the consumer nodes (camera) for this board are upstream, we will apply
the specific delay values in the DTS.

Saikiran (1):
  regulator: qcom-rpmh: Add support for regulator-off-on-delay-us