Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs

[Konrad Dybcio]

On 3/23/26 3:21 PM, Bjorn Andersson wrote:
> On Tue, Mar 03, 2026 at 05:52:53PM +0530, Pragnesh Papaniya wrote:
>>
>>
>> On 3/2/2026 6:27 PM, Konrad Dybcio wrote:
>>> On 3/2/26 12:46 PM, Pragnesh Papaniya wrote:
>>>> Add the CPU BWMON nodes for glymur SoCs.
>>>>
>>>> Co-developed-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 87 ++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 87 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> index e269cec7942c..fd947b1a17dd 100644
>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> @@ -2264,6 +2264,93 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
>>>>  			};
>>>>  		};
>>>>  
>>>> +		/* cluster0 */
>>>> +		bwmon_cluster0: pmu@100c400 {
>>>> +			compatible = "qcom,glymur-cpu-bwmon", "qcom,sdm845-bwmon";
>>>> +			reg = <0x0 0x0100c400 0x0 0x600>;
>>>> +
>>>> +			interrupts = <GIC_SPI 903 IRQ_TYPE_LEVEL_HIGH>;
>>>> +
>>>> +			interconnects = <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>>>> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
>>>> +
>>>> +			operating-points-v2 = <&cpu_bwmon_opp_table>;
>>>> +
>>>> +			cpu_bwmon_opp_table: opp-table {
>>>> +				compatible = "operating-points-v2";
>>>> +
>>>> +				opp-0 {
>>>> +					opp-peak-kBps = <800000>;
>>>> +				};
>>>
>>> Can these values remain unchanged vs hamoa? Glymur has more memory
>>> channels (as reflected in the icc driver) so the values send to rpmh
>>> will be a third lower
>>>
>>> Similarly, hamoa has roughly the same values as kona, which has half
>>> the channels
>>>
>>> Konrad
>> opp-peak-kBps is proportional to bus_width and is calculated as follows:
>>  
>> opp-peak-kBps = (Hz * node_bus_width)/ 1000
>>  
>> All the existing targets do the same, since bcm_aggregate() in 
>> bcm-voter.c divides max_peak with buswidth.
>>
> 
> So if we make the bus 100x wider, we still have/want/get the same MB/s
> throughput?

Right, that was the question I tried to ask originally.. 

glymur ebi node has 12channels, 4-wide
hamoa has 8c 4w
sm8x50 has 4c 4w

bcm-voter.c then does:

temp = bcm_div(node->sum_avg[bucket] * bcm->aux_data.width,
		node->buswidth * node->channels);
agg_avg[bucket] = max(agg_avg[bucket], temp);

temp = bcm_div(node->max_peak[bucket] * bcm->aux_data.width,
		node->buswidth);
agg_peak[bucket] = max(agg_peak[bucket], temp);


Most notably, the channel # is only taken into account for avg votes
(whereas the BWMON OPP table only has peak votes)

Perhaps the question worth actually asking is, whether the code above is
correct, and if so, why that's the case. Somewhat frustratingly, all
downstream kernels that I can find seem to corroborate that.



As for the immediate, this patch is indeed correct in that it creates the
expected behavior.

Konrad