1. Patchew
  2. linux
  3. View series

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

Pragnesh Papaniya posted 1 patch 1 month, 1 week ago 
arch/arm64/boot/dts/qcom/glymur.dtsi | 87 ++++++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
[PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Pragnesh Papaniya 1 month, 1 week ago 
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>;
+				};
+
+				opp-1 {
+					opp-peak-kBps = <2188800>;
+				};
+
+				opp-2 {
+					opp-peak-kBps = <5414400>;
+				};
+
+				opp-3 {
+					opp-peak-kBps = <6220800>;
+				};
+
+				opp-4 {
+					opp-peak-kBps = <6835200>;
+				};
+
+				opp-5 {
+					opp-peak-kBps = <8371200>;
+				};
+
+				opp-6 {
+					opp-peak-kBps = <10944000>;
+				};
+
+				opp-7 {
+					opp-peak-kBps = <12748800>;
+				};
+
+				opp-8 {
+					opp-peak-kBps = <14745600>;
+				};
+
+				opp-9 {
+					opp-peak-kBps = <16896000>;
+				};
+
+				opp-10 {
+					opp-peak-kBps = <19046400>;
+				};
+			};
+		};
+
+		/* cluster1 */
+		bwmon_cluster1: pmu@100d400 {
+			compatible = "qcom,glymur-cpu-bwmon", "qcom,sdm845-bwmon";
+			reg = <0x0 0x0100d400 0x0 0x600>;
+
+			interrupts = <GIC_SPI 901 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>;
+		};
+
+		/* cluster2 */
+		bwmon_cluster2: pmu@100e400 {
+			compatible = "qcom,glymur-cpu-bwmon", "qcom,sdm845-bwmon";
+			reg = <0x0 0x0100e400 0x0 0x600>;
+
+			interrupts = <GIC_SPI 902 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>;
+		};
+
 		cnoc_main: interconnect@1500000 {
 			compatible = "qcom,glymur-cnoc-main";
 			reg = <0x0 0x01500000 0x0 0x17080>;

---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260302-glymur_bwmon_dt-c9ad6acddd42

Best regards,
-- 
Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Bjorn Andersson 2 weeks, 2 days ago 
On Mon, 02 Mar 2026 17:16:56 +0530, Pragnesh Papaniya wrote:
> Add the CPU BWMON nodes for glymur SoCs.
> 
> 

Applied, thanks!

[1/1] arm64: dts: qcom: glymur: Add glymur BWMONs
      commit: e4945894c1cb42751559a726a6fb3193cd674802

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Konrad Dybcio 1 month, 1 week ago 
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
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Pragnesh Papaniya 1 month ago 

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.

-Pragnesh
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Bjorn Andersson 2 weeks, 2 days ago 
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
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Konrad Dybcio 2 weeks, 2 days ago 
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@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?

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
Re: [PATCH] arm64: dts: qcom: glymur: Add glymur BWMONs
Posted by Pragnesh Papaniya 2 weeks, 6 days ago 

On 3/3/2026 5:52 PM, 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.
> 
> -Pragnesh
Ping

-Pragnesh

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.