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

[Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>]

Hi Mark,

On 9/15/2026 12:04 AM, Mark Brown wrote:
> On Wed, Sep 09, 2026 at 02:34:21AM +0530, Kamal Wadhwa wrote:
> 
...> 
>> 3. If we can avoid turning the regulator off itself, so we may not need this delay
> 
>> point 3 - We evaluated this for UFS - but the problem is that the issue happens in
>> the defer probe path, so if we avoid turning off the regulator, it leads to long
>> error prints appearing for the regulator being left ON. So we couldn't take that
>> path.
> 
> I think Rob might be thinking here of something like the runtime PM
> autosuspend delay where once the final reference is dropped we wait some
> time before we actually implement the power off in hardware, thus a
> quick power cycle would never actually get implemented.  That does sound
> like a good idea if we've got issues with quick cycling, obviously the
> actual delay would still be needed but if you've got quick bounces
> happening routinely then a delay like that would allow you to avoid both
> power off and ramp delays.

I'm working with Kamal for upstreaming this series.

If I understand you correctly, instead of the approach in this driver
change (only setting the existing variable "off_on_delay"), you prefer
having a sequence somewhat like this:

1. Regulator (if configured in DT for this new behaviour) gets disable
   vote from its last enabled consumer
2. Delay timer is started
3. If regulator gets enable vote before timer expires (quick bounce),
   clear timer and return without touching regulator HW
4. Else, disable regulator when timer expires

Is this what you meant?

If the above sequence is right, where would you prefer it to be
implemented, in the regulator core file or our regulator driver file?

Thanks,
Jishnu