[PATCH v3 0/2] regulator: qcom-rpmh: Add off-on-delay support

[PATCH v3 0/2] regulator: qcom-rpmh: Add off-on-delay support

[Saikiran]

This series adds support for the standard `regulator-off-on-delay-us`
property to the Qualcomm RPMh regulator driver and updates the
corresponding Device Tree bindings.

Motivation:
On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
(LDO1, LDO3, LDO7) have large bulk capacitors and rely on passive discharge.
When these regulators are disabled, the voltage decays very slowly. If
re-enabled too quickly, the sensor experiences a brownout and fails to
initialize.

Verification:
I verified that the core `drivers/regulator/of_regulator.c` does not
currently parse `regulator-off-on-delay-us` in `of_get_regulation_constraints()`.
Therefore, the driver must parse this property explicitly and populate
`rdesc->off_on_delay` so the regulator core can enforce the constraint.

Changes in v3:
- Added Patch 1/2: Update DT bindings to allow `regulator-off-on-delay-us`
  for `qcom,rpmh-regulator` (Requested by Mark Brown).
- Updated Patch 2/2: Refined commit message to explicitly mention the
  passive discharge and bulk capacitor mechanism on the Yoga Slim 7x
  (Requested by Mark Brown).

Changes in v2:
- Moved the motivation/context from the cover letter into the commit
  message of the driver patch.

Saikiran (2):
  dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us
  regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

[PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Saikiran]

Add the standard 'regulator-off-on-delay-us' property to the list of
allowed properties for RPMh regulators.

This property is required for platforms where specific rails (like camera
LDOs) rely on passive discharge and need a mandatory off-time constraint
enforced by the regulator core.

Signed-off-by: Saikiran <bjsaikiran@gmail.com>
---
 .../devicetree/bindings/regulator/qcom,rpmh-regulator.yaml    | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
index 58bb0ad5dda4..b02311263191 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
@@ -131,6 +131,8 @@ properties:
     $ref: regulator.yaml#
     unevaluatedProperties: false
     description: BOB regulator node.
+    properties:
+      regulator-off-on-delay-us: true
     dependencies:
       regulator-allow-set-load: [ regulator-allowed-modes ]
 
@@ -140,6 +142,8 @@ patternProperties:
     $ref: regulator.yaml#
     unevaluatedProperties: false
     description: smps/ldo regulator nodes(s).
+    properties:
+      regulator-off-on-delay-us: true
     dependencies:
       regulator-allow-set-load: [ regulator-allowed-modes ]
 
-- 
2.51.0

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Rob Herring]

On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:
> Add the standard 'regulator-off-on-delay-us' property to the list of
> allowed properties for RPMh regulators.

You almost fooled me, but 'regulator-off-on-delay-us' is not a standard 
property.

> 
> This property is required for platforms where specific rails (like camera
> LDOs) rely on passive discharge and need a mandatory off-time constraint
> enforced by the regulator core.

Does enforcing some off time on all your regulators cause some negative 
impact on the ones that don't need it? If turning them back on is 
performance critical maybe don't turn them off in the first place.

> 
> Signed-off-by: Saikiran <bjsaikiran@gmail.com>
> ---
>  .../devicetree/bindings/regulator/qcom,rpmh-regulator.yaml    | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
> index 58bb0ad5dda4..b02311263191 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
> @@ -131,6 +131,8 @@ properties:
>      $ref: regulator.yaml#
>      unevaluatedProperties: false
>      description: BOB regulator node.
> +    properties:
> +      regulator-off-on-delay-us: true
>      dependencies:
>        regulator-allow-set-load: [ regulator-allowed-modes ]
>  
> @@ -140,6 +142,8 @@ patternProperties:
>      $ref: regulator.yaml#
>      unevaluatedProperties: false
>      description: smps/ldo regulator nodes(s).
> +    properties:
> +      regulator-off-on-delay-us: true
>      dependencies:
>        regulator-allow-set-load: [ regulator-allowed-modes ]
>  
> -- 
> 2.51.0
> 

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Mark Brown]

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

On Thu, Jan 29, 2026 at 11:49:42AM -0600, Rob Herring wrote:
> On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:

> > This property is required for platforms where specific rails (like camera
> > LDOs) rely on passive discharge and need a mandatory off-time constraint
> > enforced by the regulator core.

> Does enforcing some off time on all your regulators cause some negative 
> impact on the ones that don't need it? If turning them back on is 
> performance critical maybe don't turn them off in the first place.

You might see something like unexpectedly long delays resuming a runtime
suspended device.  Generally I'd say that if the delays needed for
something like this are long enough for anyone to notice they're long
enough to be disruptive.

Having said that I believe an active discharge feature in the hardware
has been identified and is being investigated, that's generally a vastly
better solution all round so hopefully this change isn't needed at all.

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

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Konrad Dybcio]

On 1/29/26 7:15 PM, Mark Brown wrote:
> On Thu, Jan 29, 2026 at 11:49:42AM -0600, Rob Herring wrote:
>> On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:
> 
>>> This property is required for platforms where specific rails (like camera
>>> LDOs) rely on passive discharge and need a mandatory off-time constraint
>>> enforced by the regulator core.
> 
>> Does enforcing some off time on all your regulators cause some negative 
>> impact on the ones that don't need it? If turning them back on is 
>> performance critical maybe don't turn them off in the first place.
> 
> You might see something like unexpectedly long delays resuming a runtime
> suspended device.  Generally I'd say that if the delays needed for
> something like this are long enough for anyone to notice they're long
> enough to be disruptive.
> 
> Having said that I believe an active discharge feature in the hardware
> has been identified and is being investigated, that's generally a vastly
> better solution all round so hopefully this change isn't needed at all.

+Jishnu, Kamal

Could you please confirm whether our hw can do that?

Konrad

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Kamal Wadhwa]

On Fri, Jan 30, 2026 at 12:05:38PM +0100, Konrad Dybcio wrote:
> On 1/29/26 7:15 PM, Mark Brown wrote:
> > On Thu, Jan 29, 2026 at 11:49:42AM -0600, Rob Herring wrote:
> >> On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:
> > 
> >>> This property is required for platforms where specific rails (like camera
> >>> LDOs) rely on passive discharge and need a mandatory off-time constraint
> >>> enforced by the regulator core.
> > 
> >> Does enforcing some off time on all your regulators cause some negative 
> >> impact on the ones that don't need it? If turning them back on is 
> >> performance critical maybe don't turn them off in the first place.
> > 
> > You might see something like unexpectedly long delays resuming a runtime
> > suspended device.  Generally I'd say that if the delays needed for
> > something like this are long enough for anyone to notice they're long
> > enough to be disruptive.
> > 
> > Having said that I believe an active discharge feature in the hardware
> > has been identified and is being investigated, that's generally a vastly
> > better solution all round so hopefully this change isn't needed at all.
> 
> +Jishnu, Kamal
> 
> Could you please confirm whether our hw can do that?

Yes, we do have setting to enable a strong pull-down to discharge the caps
in OFF state, but we dont have the option to enable/disable this from the
APPS. However most regulators will have the pull downs are enabled by
default (I'll check and confirm about this specific LDOs internally)

But I'm wondering if this is really a 'slow discharge' issue, because if the
caps discharge slowly.. shouldn't the rails be turning back ON faster
compared to when they are completely discharged (fast discharge case without
bulk caps)?

@Saikiran, Just checking if you did some analysis from HW side for this
issue.. taking plots? or may be removed the bulk caps on the HW and checked
that that issue went away? (or was still their?)

> 
> Konrad

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Mark Brown]

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

On Tue, Feb 03, 2026 at 09:50:05PM +0530, Kamal Wadhwa wrote:

> But I'm wondering if this is really a 'slow discharge' issue, because if the
> caps discharge slowly.. shouldn't the rails be turning back ON faster
> compared to when they are completely discharged (fast discharge case without
> bulk caps)?

The issue is that some of the supplies fall to a level where they cause
disruption to the devices using them but not far enough to put them back
into a power on reset state, the device browns out somehow (I'm guessing
some retained state is corrupted).  Ideally they'd have POR circuits
that handle this case well but apparently that's not the case.

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

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Kamal Wadhwa]

On Tue, Feb 03, 2026 at 04:30:27PM +0000, Mark Brown wrote:
> On Tue, Feb 03, 2026 at 09:50:05PM +0530, Kamal Wadhwa wrote:
> 
> > But I'm wondering if this is really a 'slow discharge' issue, because if the
> > caps discharge slowly.. shouldn't the rails be turning back ON faster
> > compared to when they are completely discharged (fast discharge case without
> > bulk caps)?
> 
> The issue is that some of the supplies fall to a level where they cause
> disruption to the devices using them but not far enough to put them back
> into a power on reset state, the device browns out somehow (I'm guessing
> some retained state is corrupted).  Ideally they'd have POR circuits
> that handle this case well but apparently that's not the case.

I have checked:
- ALL the pm8010 regulators have the PD enabled in OFF state by default.
- From kernel enable/disable of regulator PD settings is not allowed. Its set
  from the boot and stays as-is later.

But since its already enabled with strong PD, i guess it would not be needed
anyway.

Regards,
Kamal

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Saikiran B]

On Fri, Feb 6, 2026 at 9:50 PM Kamal Wadhwa
<kamal.wadhwa@oss.qualcomm.com> wrote:
>
> On Tue, Feb 03, 2026 at 04:30:27PM +0000, Mark Brown wrote:
> > On Tue, Feb 03, 2026 at 09:50:05PM +0530, Kamal Wadhwa wrote:
> >
> > > But I'm wondering if this is really a 'slow discharge' issue, because if the

Hi Kamal,

Thanks for checking the internal register defaults.

I can confirm it is definitely related to the power-cycling state. While I
haven't probed the pads, I validated this with two software tests:

1. The Always On Test: I modified the driver to keep the regulators
   permanently enabled (never turning off). In this state, the camera works
   100% of the time, even with rapid open/close cycles. This proves the
   crash is triggered specifically by the power-down event.

2. The Timing Threshold: Through iterative testing, I found that reopening
   the camera fails consistently if the off-time is <2.0s, but succeeds if
   the off-time is >2.3s. This 2.3s window matches the calculated RC time
   constant for a passive discharge on these rails.

If the Strong Pull Down were effectively active, the rails should drain in
milliseconds. The fact that it requires 2.3s suggests that on this unit,
the PD is either effectively disabled or too weak for the bulk capacitance
present.

As I mentioned to Mark, I have withdrawn this specific delay patch to
investigate if I can manually enforce Active Discharge (via direct RPMh
commands) to solve this at the source. But now, your note that these settings
might be locked is concerning.

> > > caps discharge slowly.. shouldn't the rails be turning back ON faster
> > > compared to when they are completely discharged (fast discharge case without
> > > bulk caps)?
> >
> > The issue is that some of the supplies fall to a level where they cause
> > disruption to the devices using them but not far enough to put them back
> > into a power on reset state, the device browns out somehow (I'm guessing
> > some retained state is corrupted).  Ideally they'd have POR circuits
> > that handle this case well but apparently that's not the case.
>
> I have checked:
> - ALL the pm8010 regulators have the PD enabled in OFF state by default.
> - From kernel enable/disable of regulator PD settings is not allowed. Its set
>   from the boot and stays as-is later.
>
> But since its already enabled with strong PD, i guess it would not be needed
> anyway.
>
> Regards,
> Kamal
>

Regards,
Saikiran

Re: [PATCH v3 1/2] dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us

[Kamal Wadhwa]

On Sun, Feb 08, 2026 at 06:37:24PM +0530, Saikiran B wrote:
> On Fri, Feb 6, 2026 at 9:50 PM Kamal Wadhwa
> <kamal.wadhwa@oss.qualcomm.com> wrote:
> >
> > On Tue, Feb 03, 2026 at 04:30:27PM +0000, Mark Brown wrote:
> > > On Tue, Feb 03, 2026 at 09:50:05PM +0530, Kamal Wadhwa wrote:
> > >
> > > > But I'm wondering if this is really a 'slow discharge' issue, because if the
> 
> Hi Kamal,
> 
> Thanks for checking the internal register defaults.
> 
> I can confirm it is definitely related to the power-cycling state. While I
> haven't probed the pads, I validated this with two software tests:
> 
> 1. The Always On Test: I modified the driver to keep the regulators
>    permanently enabled (never turning off). In this state, the camera works
>    100% of the time, even with rapid open/close cycles. This proves the
>    crash is triggered specifically by the power-down event.
> 
> 2. The Timing Threshold: Through iterative testing, I found that reopening
>    the camera fails consistently if the off-time is <2.0s, but succeeds if
>    the off-time is >2.3s. This 2.3s window matches the calculated RC time
>    constant for a passive discharge on these rails.
> 
> If the Strong Pull Down were effectively active, the rails should drain in
> milliseconds. The fact that it requires 2.3s suggests that on this unit,
> the PD is either effectively disabled or too weak for the bulk capacitance
> present.
> 
> As I mentioned to Mark, I have withdrawn this specific delay patch to
> investigate if I can manually enforce Active Discharge (via direct RPMh
> commands) to solve this at the source. But now, your note that these settings
> might be locked is concerning.

I discussed about your concerns, and it seems that we have some boot side DT config 
that can be configured to enable/disable the strong PD ( its not available
from HLOS though)

you can refer to Doc for same here:-
https://docs.qualcomm.com/doc/80-70023-4/topic/tools.html?product=895724676033554725&facet=Boot&version=1.7

forum to ask questions about it:-
https://mysupport.qualcomm.com/supportforums/s/

> 
> Regards,
> Saikiran

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

[Saikiran]

The core regulator framework supports enforcing a physical off-time via
standard properties, but the `qcom-rpmh-regulator` driver currently ignores
them.

The issue is platform-specific: The Lenovo Yoga Slim 7x (Snapdragon X Elite)
has large bulk capacitors on the camera rails (LDO1, LDO3, LDO7). When these
regulators are disabled, the voltage decays very slowly (passive discharge).

If the rail is re-enabled before this discharge completes, the sensor
experiences a brownout and fails to initialize.

Add support for parsing the 'regulator-off-on-delay-us' property from
the device tree to enforce this physical constraint.

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 v3 0/2] regulator: qcom-rpmh: Add off-on-delay support

[Kamal Wadhwa]

On Wed, Jan 28, 2026 at 12:32:09AM +0530, Saikiran wrote:
> This series adds support for the standard `regulator-off-on-delay-us`
> property to the Qualcomm RPMh regulator driver and updates the
> corresponding Device Tree bindings.
> 
> Motivation:
> On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
> (LDO1, LDO3, LDO7) have large bulk capacitors and rely on passive discharge.
> When these regulators are disabled, the voltage decays very slowly. If
> re-enabled too quickly, the sensor experiences a brownout and fails to
> initialize.
> 
> Verification:
> I verified that the core `drivers/regulator/of_regulator.c` does not
> currently parse `regulator-off-on-delay-us` in `of_get_regulation_constraints()`.
> Therefore, the driver must parse this property explicitly and populate
> `rdesc->off_on_delay` so the regulator core can enforce the constraint.
> 
> Changes in v3:
> - Added Patch 1/2: Update DT bindings to allow `regulator-off-on-delay-us`
>   for `qcom,rpmh-regulator` (Requested by Mark Brown).
> - Updated Patch 2/2: Refined commit message to explicitly mention the
>   passive discharge and bulk capacitor mechanism on the Yoga Slim 7x
>   (Requested by Mark Brown).
> 
> Changes in v2:
> - Moved the motivation/context from the cover letter into the commit
>   message of the driver patch.
> 
> Saikiran (2):
>   dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us
>   regulator: qcom-rpmh: Add support for regulator-off-on-delay-us

Hi Mark, Bjorn, Konrad and all,

We have another UFS issue on QCS8300 RB4 EVK, where it seems this patch is
helping.

Issue is seen 2/10 reboots and it happens in the UFS probe defer path:

1. UFS probe takes regulator handle for VCC(vreg_l8a) of UFS host controller.
2. UFS probe enables the regulator
3. UFS probe defers (due to some other dependency un-related to regulator)
4. UFS regulator disabled on probe exit
5. UFS re-attempts probe and re-enables the regulator
6. UFS init sequence runs -> UFS NOP OUT command failed (no shell) 

Issue Log:

[    6.583836] ufshcd-qcom 1d84000.ufs: ufshcd_verify_dev_init: NOP OUT failed -11
[    6.592780] ufshcd-qcom 1d84000.ufs: ufshcd_async_scan failed: -11

NOTE
- Issue is not seen in first probe attempt, because UFS regulators are left ON
  from bootloader, which gives enough time between rail turn ON and UFS init
  sequence start.  However in issue case, it seems re-probe is happening too
  fast, which causes init sequence to fail and UFS brownouts (similar to camera
  sensor case)

- Also, we compared this board with other RBxx EVK boards for UFS rail, it
  seems that this board has more caps on the VCC regulator, as the board is
  designed to have both EMMC and UFS, and we have DT option to pick one of them.

  So for EMMC those extra caps were added and they are impacting rampup on VCC.

Since this is not entirely a UFS part issue, but a board design constraint, it
seems better if we handle this in the regulator side itself, as adding it in the
UFS driver may not be acceptable from UFS reviewers.

Please share your opinion, if this seems to be good reason to accept this patch?

Regards,
Kamal