On Fri, Jan 30, 2026 at 12:05:38PM +0100, Konrad Dybcio wrote:

On 1/29/26 7:15 PM, Mark Brown wrote:

quoted

On Thu, Jan 29, 2026 at 11:49:42AM -0600, Rob Herring wrote:

quoted

On Wed, Jan 28, 2026 at 12:32:10AM +0530, Saikiran wrote:

quoted

quoted

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.

quoted

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