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

[Kamal Wadhwa]

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.

> 
> Konrad