Re: [PATCH v2 2/4] soc: qcom: rpmh: Add support to read back resource settings

[Bjorn Andersson]

On Mon, Oct 27, 2025 at 04:47:26PM +0100, Konrad Dybcio wrote:
> On 10/27/25 3:38 PM, Neil Armstrong wrote:
> > On 10/27/25 14:29, Konrad Dybcio wrote:
> >> On 10/23/25 11:46 AM, Maulik Shah (mkshah) wrote:
> >>>
> >>>
> >>> On 10/23/2025 2:39 PM, Konrad Dybcio wrote:
> >>>> On 10/23/25 10:57 AM, Maulik Shah (mkshah) wrote:
> >>>>>
> >>>>>
> >>>>> On 10/23/2025 1:47 PM, Konrad Dybcio wrote:
> >>>>>> On 10/23/25 6:46 AM, Maulik Shah (mkshah) wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/23/2025 2:51 AM, Bjorn Andersson wrote:
> >>>>>>>> On Wed, Oct 22, 2025 at 02:38:54AM +0530, Kamal Wadhwa wrote:
> >>>>>>>>> From: Maulik Shah <maulik.shah@xxxxxxxxxxxxxxxx>
> >>>>>>>>>
> >>>>>>>>> All rpmh_*() APIs so far have supported placing votes for various
> >>>>>>>>> resource settings but the H/W also have option to read resource
> >>>>>>>>> settings.
> >>>>>>>>>
> >>>>>>>>> This change adds a new rpmh_read() API to allow clients
> >>>>>>>>> to read back resource setting from H/W. This will be useful for
> >>>>>>>>> clients like regulators, which currently don't have a way to know
> >>>>>>>>> the settings applied during bootloader stage.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Allow me to express my disappointment over the fact that you sat on this
> >>>>>>>> for 7 years!
> >>>>>>>
> >>>>>>> This was a dead API (even in downstream) with no user since SDM845/ 7 years.
> >>>>>>> Read support was eventually removed from downstream driver too for the same reason.
> >>>>>>> There were early discussions to remove read support from RSC H/W, due to lack of users.
> >>>>>>> Its not realized yet and all SoCs still supports read.
> >>>>>>
> >>>>>> Can we read BCM states from HLOS this way too?
> >>>>>
> >>>>> Yes, Any of ARC/BCM/VRM can be read to get HLOS/DRV2 votes.
> >>>>
> >>>> Wow this is amazing..
> >>>>
> >>>> Do you have code for this already, or should I hack on it?
> >>>
> >>> No, it won't be of much help, as i said above it gets HLOS/DRV2 votes only for a given resource.
> >>> More specifically, the read does not give the aggregated vote result across all the DRVs.
> >>
> >> Hm, perhaps it could still be of *some* use
> >>
> >> But maybe reading back rpmhpd and rpmhcc states would be of more
> >> use!
> > 
> > The interconnect core definitely supports reading back the state at boot.
> 
> Maulik probably isn't impressed with us only being able to provide
> information about HLOS votes, as e.g. ADSP could be voting on the same
> bus in parallel.
> 
> I suppose the very same applies to what I suggested with clk and rpmhpd
> although probably it's less of a problem there
> 

Reading back the state serves the purpose of dealing with smooth
transition from bootloader, which we very much would like to have.

Being able to read the aggregated state is useful for debugging, but
it's a shared state that can change at any point in time, so we should
never act upon such information.

Regards,
Bjorn

> Konrad