Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The SCMI cpufreq driver ignores DT `operating-points-v2` and interconnect properties, leaving LLCC and DDR bandwidth unscaled despite commit message claims.
--

commit a13e6fe2fe07b0245da4da3915362899fce3df5b
Author: Aaron Kling <webgeek1234@gmail.com>

arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

This commit adds operating-points-v2 tables and interconnect paths to the
CPU nodes for the SM8750. The stated goal is to scale LLCC and DDR
frequency based on the CPU cores' current hardware operating point.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> index fafed417c66fc..6f44c39364991 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> @@ -44,6 +44,11 @@ cpu0: cpu@0 {
>  			next-level-cache = <&l2_0>;
>  			power-domains = <&cpu_pd0>, <&scmi_dvfs 0>;
>  			power-domain-names = "psci", "perf";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> +					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> +					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;

[Severity: Medium]
Will these device tree properties be parsed and used by the active cpufreq
driver?

Since this CPU is managed by the SCMI protocol (as indicated by the
scmi_dvfs power domain), the SCMI cpufreq driver dynamically fetches OPPs
directly from firmware.

It appears the SCMI drivers bypass parsing the device tree
operating-points-v2 tables entirely, meaning the OPP core won't trigger
bandwidth scaling during CPU frequency transitions. Does this leave the LLCC
and DDR bandwidth unscaled, contrary to the commit message?

[ ... ]

> +	cpu0_opp_table: opp-table-cpu0 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-384000000 {
> +			opp-hz = /bits/ 64 <384000000>;
> +			opp-peak-kBps = <(547000 * 16) (350000 * 4)>;

[Severity: Medium]
Is this bandwidth scaling data accessible if SCMI is handling the OPPs?

Because the SCMI cpufreq driver doesn't use dev_pm_opp_of_add_table(),
these static bandwidth mappings appear to be inert dead code. Is there
another mechanism being used to pass this interconnect bandwidth data
alongside the SCMI managed operating points?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605-sm8750-ddr-bw-scaling-v1-1-f39f918c95a7@gmail.com?part=1