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

[Mark Brown <broonie@kernel.org>]

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

On Wed, Sep 16, 2026 at 01:35:09PM +0530, Jishnu Prakash wrote:
> 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?

That's what I understand Rob's suggestion to be.  Like I say that would
still need any minimum off time enforcement.

> 
> 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
> 

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