Re: [PATCH 0/3] Qualcomm: rpmh and regulator fixes

[Casey Connolly <casey.connolly@linaro.org>]

On 01/05/2026 07:59, Sumit Garg wrote:
> Hi Casey,
> 
> On Mon, Apr 13, 2026 at 01:06:13PM +0200, Casey Connolly wrote:
>> The RPMh API is frustratingly complicated and lacks public
>> documentation. With the Linux drivers being the only available sources
>> but are highly asynchronous and thus hard to translate to U-Boot.
> 
> There is new source of synchronous RPMh upstream driver which is being
> pushed to upstream OP-TEE project here [1]. I agree U-Boot single
> threaded execution model requires drivers to be simplified coming from
> highly asynchronous Linux context.

ahh, that's a nice reference to have but still a big hard to follow.

I think this might be a case where it makes sense to diverge more from
Linux. The OP-TEE driver also seems to be asynchronous (just not IRQ
driven).

There's definitely a bunch more unsolved bugs with the U-Boot driver,
restricting it to just handle one cmd per request and only ever use a
single TCS at least we know it works in that configuration. Obviously
not really ideal.

> 
> [1] https://github.com/OP-TEE/optee_os/pull/7796
> 
>>
>> The main issue seems to relate to sending multiple commands in a single
>> TCS request, currently this is only done by the interconnect driver and
>> while this may not be the underlying cause it seems to be safer to avoid
>> this for now.
> 
> Can you share which particular peripheral is being tested here to
> reproduce the issues you are facing?

The repro is just booting Linux on sm8650 HDK after U-Boot's ICC driver
has sent votes. Linux will either hang during rpmh regulator probing or
get RPMh IRQ spammed and then crash.

I spent a bit of time in Trace32 but it didn't seem like I was gonna get
anywhere with that with my current knowledge. If you could advise (maybe
off-list?) on how to actually debug RPMh requests that would be amazing!
Perhaps I should revisit hansei.py? But yeah it would help a lot to get
some pointers on that.

> 
>>
>> Adjust the bcm-voter driver to avoid sending multiple commands per
>> write, and additionally adjust how we send RPMh requests as well as
>> improve the cleanup we do prior to booting the OS.
>>
> 
> Aswin,
> 
> Is there something you can help Casey with this multiple RPMh requests
> issue?
> 
>> Lastly, add a missing piece to the rpmh regulator driver to ensure
>> that when a supply gets enabled we also propagate a vote to its parent
>> supply. This seems to have been missed from the original port (perhaps
>> because the Linux regulator core handles this automatically?) but it is
>> necessary for some peripherals on some boards to work (e.g. to ensure
>> that the spms supplier for an LDO gets enabled).
>>
> 
> Again it will be better if you list down the specific peripherals here.
> 
> -Sumit
> 
>> ---
>> Casey Connolly (3):
>>       soc/qcom: rpmh: properly fix synchronous requests
>>       soc/qcom: rpmh: only allow rpmh writes of a single command
>>       power: regulator: qcom-rpmh: propagate votes to parent supplies
>>
>>  drivers/interconnect/qcom/bcm-voter.c         | 16 +++---
>>  drivers/power/regulator/qcom-rpmh-regulator.c | 35 +++++++++++++-
>>  drivers/soc/qcom/rpmh-rsc.c                   | 70 ++++++++++++++++++++-------
>>  drivers/soc/qcom/rpmh.c                       |  6 +++
>>  4 files changed, 102 insertions(+), 25 deletions(-)
>> ---
>> base-commit: c704af3c8b0f37929bce8c2a4bba27d6e89919c7
>>
>> // Casey (she/they)
>>

-- 
// Casey (she/her)