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

[Konrad Dybcio]

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?

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

Konrad