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

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
>

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.

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

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

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.

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

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