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

[Bjorn Andersson <andersson@kernel.org>]

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@oss.qualcomm.com>
> >> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> >> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
> >> ---
> >>  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?

Regards,
Bjorn

> -Pragnesh