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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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?

Konrad