Re: [PATCH v6 3/4] regulator: qcom-rpmh: readback voltage/bypass/mode set during bootup

[Konrad Dybcio]

On 9/7/26 2:59 PM, Kamal Wadhwa wrote:
> On Tue, Sep 01, 2026 at 11:49:42AM +0200, Konrad Dybcio wrote:
>> On 8/1/26 10:00 AM, Kamal Wadhwa wrote:
>>> Currently, during regulator registration, regulator framework sends an
>>> unnecessary `min-microvolts` request for the rpmh-regulator device. This
>>> happens because in current design, we do not have a way to readback the
>>> voltage settings that was set during the bootloader stage.
>>>
>>> Fix this by using the rpmh_read() API to read the regulator voltage
>>> settings done during boot and make it available to regulator framework
>>> from the very first read after the bootup.
>>>
>>> Also use this API to read the mode/bypass settings as well. This will
>>> provide the regulator framework a sense of the initial settings done by
>>> bootloader and thus preventing any redundant writes for any setting post
>>> bootup incase the same setting was already applied during bootup.
>>>
>>> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@xxxxxxxxxxxxxxxx>
>>> ---
>>
>> SC8180X Primus hangs with this patch applied and so does SM8150 HDK.
> 
> Ok, i did see some issues on SM8550 but those were mainly related to the
> voltage range check leading to some regulator failing to probe, for that
> this below change may help.
> https://lore.kernel.org/all/20260720-b4-regulator-core-clamp-voltage-v1-1-8e5eec076a8e@xxxxxxxxxxxxxxxx/
> 
> But i suppose you may already have it?

Yes


> do you see the problem with the rpmh_read() or in the voltage range check?

Applying

20260812-rpmh-timeout-debug-v1-v3-0-68c0a40dce23@xxxxxxxxxxxxxxxx

I get:

[   12.735771] qcom_rpmh RSC:apps_rsc
[   12.739294] qcom_rpmh Request: tcs-in-use:YES state=2 wait_for_compl=1
[   12.749622] qcom_rpmh TCS=0 [ctrlr-sts:BUSY amc-mode:0x1010000 irq-sts:WAITING]
[   12.763769] qcom_rpmh        CMD=0 [addr=0x43100(VRM/smpc8) data=0x7 resp-required sts=triggered+sent-to-aoss]
[   12.781024] qcom_rpmh Request: tcs-in-use:YES state=2 wait_for_compl=1
[   12.797493] qcom_rpmh TCS=1 [ctrlr-sts:BUSY amc-mode:0x1010000 irq-sts:WAITING]
[   12.811733] qcom_rpmh        CMD=0 [addr=0x40000(VRM/smpa5) data=0x0 resp-required sts=triggered+sent-to-aoss]
[   12.829006] qcom_rpmh HW IRQ 37 is NOT PENDING at GIC
[   12.843942] qcom_rpmh Completion is not done
[   12.853536] qcom_rpmh ERROR: Accelerator(s) at AOSS did not respond

Neither S8C nor S5A are "special", neither of them feeds an
ARC resource (at a glance, anyway)

so it's the read part,

RPMH_REGULATOR_REG_VRM_VOLTAGE and RPMH_REGULATOR_REG_VRM_MODE stall

RPMH_REGULATOR_REG_ENABLE interestingly doesn't

Konrad