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

[Kamal Wadhwa]

On Mon, Jun 29, 2026 at 02:13:00PM +0200, Konrad Dybcio wrote:
> On 6/25/26 12:16 AM, Kamal Wadhwa wrote:
> > On Tue, Jun 16, 2026 at 01:48:50PM +0200, Konrad Dybcio wrote:
> >> On 5/15/26 1:16 PM, Kamal Wadhwa wrote:
> >>> 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?
> >>
> >> Is that board in production already, or is that something that can be fixed?
> > 
> > yes, it cannot be fixed in HW, as the board is already in production.
> 
> Re-reading this thread, RobH's worry here:
> 
> https://lore.kernel.org/all/20260129174829.GA1324020-robh@xxxxxxxxxx/
> 
> seems to be misguided - AFAICU this property would be set on each
> regulator separately, not globally for all regulators under a given
> PMIC - is that right?

Yes, this is per-regulator and not globally applied.

> 
> In that case, I see no real downside in allowing that, especially given
> it would/should be used sparingly and only in cases like you mentioned
> where the board has some quirks

yes. we can use this sparingly for such board issues.

@Mark, @Rob - can you please comment if you think this is acceptable?

> 
> Konrad