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

[Manivannan Sadhasivam]

On Fri, May 15, 2026 at 04:46:47PM +0530, 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.
> 

Ofc. UFS driver shouldn't deal with this board specific regulator constraint.
Please work on addressing Rob's concern to take this series forward.

- Mani

-- 
மணிவண்ணன் சதாசிவம்