[PATCH 0/3] Add cpufreq to MSM8960

[PATCH 0/3] Add cpufreq to MSM8960

[Rudraksha Gupta via B4 Relay]

Similar to APQ8064, cpufreq is enabled with this small patch series.

Tests:

// Show available frequencies
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
384000 486000 594000 702000 810000 918000 1026000 1080000 1134000 1242000 1350000 1512000
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies
384000 486000 594000 702000 810000 918000 1026000 1080000 1134000 1242000 1350000 1512000
 
// Show current governor
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
schedutil
 
// set low freq
$ echo 384000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
384000
 
// set mid freq
$ echo 1026000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1026000
 
// set max freq
$ echo 1512000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1512000
 
// set low freq
$ echo 384000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
384000
 
// set mid freq
$ echo 1026000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1026000
 
// set max freq
$ echo 1512000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1512000
 
// SAW2 regulators
$ cat /sys/class/regulator/regulator.*/microvolts 2>/dev/null | head -2
1200000
1150000

Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
Rudraksha Gupta (3):
      dt-bindings: soc: qcom: saw2: Rename MSM8960 SAW2 compatible to v1.1
      soc: qcom: spm: Add MSM8960 SAW2 CPU support
      ARM: dts: qcom: msm8960: Add CPU frequency scaling support

 .../devicetree/bindings/soc/qcom/qcom,saw2.yaml    |   2 +-
 arch/arm/boot/dts/qcom/qcom-msm8960.dtsi           | 133 ++++++++++++++++++++-
 drivers/soc/qcom/spm.c                             |  20 +++-
 3 files changed, 151 insertions(+), 4 deletions(-)
---
base-commit: 3131ff5a117498bb4b9db3a238bb311cbf8383ce
change-id: 20260513-expressatt_cpufreq-66638ba8d156
prerequisite-message-id: <20260503-expressatt-touchkey-v1-1-f7dd5db64e0d@gmail.com>
prerequisite-patch-id: 8de4de7909722ccaf385c4224f25a623eaa72c28
prerequisite-message-id: <20260503-expressatt_camera_flash-v5-0-95524506a799@gmail.com>
prerequisite-patch-id: ab8b8d87fd2d518c4c5b5dace3f22238d1abbe49
prerequisite-patch-id: a6ab585bad167db61d13b10c3912018ec94cdfd9
prerequisite-patch-id: 7ef7df61e7ef6476a35811d765f522f793d9ecc7
prerequisite-message-id: <20260401-expressatt_fuel_guage-v3-0-9674cfc0b5a2@gmail.com>
prerequisite-patch-id: 27c37aa51fe76043b4998137d106689ed5ae6c91
prerequisite-patch-id: e477ee37abf167c55659f5e591b070b176187ca7
prerequisite-patch-id: 9680b63831f2be63607bff2175639c1987af5e85
prerequisite-patch-id: ee275dc3aec6159072d0a9efb66d18468a72ad57

Best regards,
-- 
Rudraksha Gupta <guptarud@gmail.com>

[PATCH 1/3] dt-bindings: soc: qcom: saw2: Rename MSM8960 SAW2 compatible to v1.1

[Rudraksha Gupta via B4 Relay]

From: Rudraksha Gupta <guptarud@gmail.com>

Rename qcom,msm8960-saw2-cpu to qcom,msm8960-saw2-v1.1-cpu to follow
the naming convention used by other SAW2 compatibles that include the
hardware version (e.g. qcom,apq8064-saw2-v1.1-cpu).

The MSM8960 uses SAW2 v1.1, the same hardware version as the APQ8064.

Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
index c2f1f5946cfa..ff0e2697a7c6 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
@@ -37,7 +37,7 @@ properties:
           - qcom,msm8939-saw2-v3.0-cpu
           - qcom,msm8226-saw2-v2.1-cpu
           - qcom,msm8226-saw2-v2.1-l2
-          - qcom,msm8960-saw2-cpu
+          - qcom,msm8960-saw2-v1.1-cpu
           - qcom,msm8974-saw2-v2.1-cpu
           - qcom,msm8974-saw2-v2.1-l2
           - qcom,msm8976-gold-saw2-v2.3-l2

-- 
2.54.0

[PATCH 2/3] soc: qcom: spm: Add MSM8960 SAW2 CPU support

[Rudraksha Gupta via B4 Relay]

From: Rudraksha Gupta <guptarud@gmail.com>

The MSM8960 uses SAW2 v1.1, the same hardware version as the APQ8064.
Add SPM register data so that the SAW2 driver can program the correct
SPM sequences and PMIC parameters for MSM8960 CPUs.

The register layout, SPM sequences, voltage range, and regulator
parameters are shared with APQ8064. The only difference is pmic_dly:
0x03020004 on MSM8960 vs 0x02020004 on APQ8064.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3353-L3381
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 drivers/soc/qcom/spm.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
index f75659fff287..596431b00a03 100644
--- a/drivers/soc/qcom/spm.c
+++ b/drivers/soc/qcom/spm.c
@@ -233,7 +233,7 @@ static const u16 spm_reg_offset_v1_1[SPM_REG_NR] = {
 
 static void smp_set_vdd_v1_1(void *data);
 
-/* SPM register data for 8064 */
+/* SPM register data for 8064, 8960 */
 static struct linear_range spm_v1_1_regulator_range =
 	REGULATOR_LINEAR_RANGE(700000, 0, 56, 12500);
 
@@ -253,6 +253,22 @@ static const struct spm_reg_data spm_reg_8064_cpu = {
 	.ramp_delay = 1250,
 };
 
+static const struct spm_reg_data spm_reg_8960_cpu = {
+	.reg_offset = spm_reg_offset_v1_1,
+	.spm_cfg = 0x1F,
+	.pmic_dly = 0x03020004,
+	.pmic_data[0] = 0x0084009C,
+	.pmic_data[1] = 0x00A4001C,
+	.seq = { 0x03, 0x0F, 0x00, 0x24, 0x54, 0x10, 0x09, 0x03, 0x01,
+		0x10, 0x54, 0x30, 0x0C, 0x24, 0x30, 0x0F },
+	.start_index[PM_SLEEP_MODE_STBY] = 0,
+	.start_index[PM_SLEEP_MODE_SPC] = 2,
+	.set_vdd = smp_set_vdd_v1_1,
+	.range = &spm_v1_1_regulator_range,
+	.init_uV = 1300000,
+	.ramp_delay = 1250,
+};
+
 static inline void spm_register_write(struct spm_driver_data *drv,
 					enum spm_reg reg, u32 val)
 {
@@ -501,6 +517,8 @@ static const struct of_device_id spm_match_table[] = {
 	  .data = &spm_reg_8974_8084_cpu },
 	{ .compatible = "qcom,apq8064-saw2-v1.1-cpu",
 	  .data = &spm_reg_8064_cpu },
+	{ .compatible = "qcom,msm8960-saw2-v1.1-cpu",
+	  .data = &spm_reg_8960_cpu },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, spm_match_table);

-- 
2.54.0

[PATCH 3/3] ARM: dts: qcom: msm8960: Add CPU frequency scaling support

[Rudraksha Gupta via B4 Relay]

From: Rudraksha Gupta <guptarud@gmail.com>

Enable Krait DVFS on MSM8960 by adding the required device tree nodes:

- OPP table with 12 operating points from 384 MHz to 1.512 GHz, with
  per-PVS voltages for slow, nominal, and fast silicon bins.
- Krait clock controller (krait-cc-v1) driving the CPU muxes from
  PLL9/PLL10, ACC aux outputs, and PXO.
- PVS efuse nvmem cell in qfprom for the cpufreq-nvmem driver to
  read the speed-bin and process voltage class.
- CPU idle state for Standalone Power Collapse (SPC).
- operating-points-v2, clocks, cpu-supply, and cpu-idle-states wired
  into both CPU nodes.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/acpuclock-8960.c#L120-L235
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 133 ++++++++++++++++++++++++++++++-
 1 file changed, 131 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index a427f0f41cd1..b5b9239c7aa0 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -54,6 +54,10 @@ cpu@0 {
 			reg = <0>;
 			enable-method = "qcom,kpss-acc-v1";
 			device_type = "cpu";
+			operating-points-v2 = <&cpu_opp_table>;
+			clocks = <&kraitcc 0>;
+			cpu-supply = <&saw0_vreg>;
+			cpu-idle-states = <&cpu_spc>;
 			next-level-cache = <&l2>;
 			qcom,acc = <&acc0>;
 			qcom,saw = <&saw0>;
@@ -64,6 +68,10 @@ cpu@1 {
 			reg = <1>;
 			enable-method = "qcom,kpss-acc-v1";
 			device_type = "cpu";
+			operating-points-v2 = <&cpu_opp_table>;
+			clocks = <&kraitcc 1>;
+			cpu-supply = <&saw1_vreg>;
+			cpu-idle-states = <&cpu_spc>;
 			next-level-cache = <&l2>;
 			qcom,acc = <&acc1>;
 			qcom,saw = <&saw1>;
@@ -74,6 +82,116 @@ l2: l2-cache {
 			cache-level = <2>;
 			cache-unified;
 		};
+
+		idle-states {
+			cpu_spc: cpu-spc {
+				compatible = "qcom,idle-state-spc", "arm,idle-state";
+				entry-latency-us = <400>;
+				exit-latency-us = <900>;
+				min-residency-us = <3000>;
+			};
+		};
+	};
+
+	cpu_opp_table: opp-table-cpu {
+		compatible = "operating-points-v2-krait-cpu";
+		nvmem-cells = <&pvs_efuse>;
+
+		opp-384000000 {
+			opp-hz = /bits/ 64 <384000000>;
+			opp-microvolt-speed0-pvs0-v0 = <950000>;
+			opp-microvolt-speed0-pvs1-v0 = <900000>;
+			opp-microvolt-speed0-pvs3-v0 = <850000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-486000000 {
+			opp-hz = /bits/ 64 <486000000>;
+			opp-microvolt-speed0-pvs0-v0 = <975000>;
+			opp-microvolt-speed0-pvs1-v0 = <925000>;
+			opp-microvolt-speed0-pvs3-v0 = <875000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-594000000 {
+			opp-hz = /bits/ 64 <594000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1000000>;
+			opp-microvolt-speed0-pvs1-v0 = <950000>;
+			opp-microvolt-speed0-pvs3-v0 = <900000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-702000000 {
+			opp-hz = /bits/ 64 <702000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1025000>;
+			opp-microvolt-speed0-pvs1-v0 = <975000>;
+			opp-microvolt-speed0-pvs3-v0 = <925000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-810000000 {
+			opp-hz = /bits/ 64 <810000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1075000>;
+			opp-microvolt-speed0-pvs1-v0 = <1025000>;
+			opp-microvolt-speed0-pvs3-v0 = <975000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-918000000 {
+			opp-hz = /bits/ 64 <918000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1100000>;
+			opp-microvolt-speed0-pvs1-v0 = <1050000>;
+			opp-microvolt-speed0-pvs3-v0 = <1000000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1026000000 {
+			opp-hz = /bits/ 64 <1026000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1125000>;
+			opp-microvolt-speed0-pvs1-v0 = <1075000>;
+			opp-microvolt-speed0-pvs3-v0 = <1025000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1134000000 {
+			opp-hz = /bits/ 64 <1134000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1175000>;
+			opp-microvolt-speed0-pvs1-v0 = <1125000>;
+			opp-microvolt-speed0-pvs3-v0 = <1075000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1242000000 {
+			opp-hz = /bits/ 64 <1242000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1200000>;
+			opp-microvolt-speed0-pvs1-v0 = <1150000>;
+			opp-microvolt-speed0-pvs3-v0 = <1100000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1350000000 {
+			opp-hz = /bits/ 64 <1350000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1225000>;
+			opp-microvolt-speed0-pvs1-v0 = <1175000>;
+			opp-microvolt-speed0-pvs3-v0 = <1125000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1458000000 {
+			opp-hz = /bits/ 64 <1458000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1237500>;
+			opp-microvolt-speed0-pvs1-v0 = <1187500>;
+			opp-microvolt-speed0-pvs3-v0 = <1137500>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
+
+		opp-1512000000 {
+			opp-hz = /bits/ 64 <1512000000>;
+			opp-microvolt-speed0-pvs0-v0 = <1250000>;
+			opp-microvolt-speed0-pvs1-v0 = <1200000>;
+			opp-microvolt-speed0-pvs3-v0 = <1150000>;
+			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;
+		};
 	};
 
 	memory@80000000 {
@@ -81,6 +199,13 @@ memory@80000000 {
 		reg = <0x80000000 0>;
 	};
 
+	kraitcc: clock-controller {
+		compatible = "qcom,krait-cc-v1";
+		clocks = <&gcc PLL9>, <&gcc PLL10>, <&acc0>, <&acc1>, <&pxo_board>;
+		clock-names = "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb";
+		#clock-cells = <1>;
+	};
+
 	soc: soc {
 		compatible = "simple-bus";
 		ranges;
@@ -112,6 +237,10 @@ qfprom: efuse@700000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			pvs_efuse: pvs@c0 {
+				reg = <0xc0 0x04>;
+			};
+
 			tsens_calib: calib@404 {
 				reg = <0x404 0x10>;
 			};
@@ -348,7 +477,7 @@ acc0: clock-controller@2088000 {
 		};
 
 		saw0: power-manager@2089000 {
-			compatible = "qcom,msm8960-saw2-cpu", "qcom,saw2";
+			compatible = "qcom,msm8960-saw2-v1.1-cpu", "qcom,saw2";
 			reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
 
 			saw0_vreg: regulator {
@@ -367,7 +496,7 @@ acc1: clock-controller@2098000 {
 		};
 
 		saw1: power-manager@2099000 {
-			compatible = "qcom,msm8960-saw2-cpu", "qcom,saw2";
+			compatible = "qcom,msm8960-saw2-v1.1-cpu", "qcom,saw2";
 			reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
 
 			saw1_vreg: regulator {

-- 
2.54.0

Re: [PATCH 1/3] dt-bindings: soc: qcom: saw2: Rename MSM8960 SAW2 compatible to v1.1

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ABI breakage and broken bisectability: The patch removes the existing 'qcom,msm8960-saw2-cpu' compatible string from the YAML binding without retaining it.
--

commit 5f6f37c2425f00a08baf814227401f4026243b11
Author: Rudraksha Gupta <guptarud@gmail.com>

dt-bindings: soc: qcom: saw2: Rename MSM8960 SAW2 compatible to v1.1

This commit renames the qcom,msm8960-saw2-cpu compatible string to
qcom,msm8960-saw2-v1.1-cpu in the SAW2 bindings. The change aligns the
MSM8960 naming convention with other SAW2 compatibles that explicitly
include their hardware version.

> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
> index c2f1f5946cfaa..ff0e2697a7c60 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
> @@ -37,7 +37,7 @@ properties:
>            - qcom,msm8939-saw2-v3.0-cpu
>            - qcom,msm8226-saw2-v2.1-cpu
>            - qcom,msm8226-saw2-v2.1-l2
> -          - qcom,msm8960-saw2-cpu
> +          - qcom,msm8960-saw2-v1.1-cpu

Will removing the older compatible string break backward compatibility for
existing device tree blobs that rely on it? Standard practice is usually
to retain the old string, sometimes marked as deprecated, to preserve the
binding ABI.

Also, since the in-tree device tree files still use the old string until
they are updated in a later commit in the series, does this removal cause
make dtbs_check to fail at this exact commit, breaking bisectability?

>            - qcom,msm8974-saw2-v2.1-cpu
>            - qcom,msm8974-saw2-v2.1-l2
>            - qcom,msm8976-gold-saw2-v2.3-l2

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-expressatt_cpufreq-v1-0-487fd2d78859@gmail.com?part=1

Re: [PATCH 2/3] soc: qcom: spm: Add MSM8960 SAW2 CPU support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Probe will panic or Oops due to a division by zero in spm_register_regulator() when computing drv->volt_sel.
--

commit 4745d4815a10beefae8a9bba0dd4e906c2f9bd24
Author: Rudraksha Gupta <guptarud@gmail.com>

soc: qcom: spm: Add MSM8960 SAW2 CPU support

The MSM8960 uses SAW2 v1.1, the same hardware version as the APQ8064. This
adds SPM register data to program the correct SPM sequences and PMIC
parameters for MSM8960 CPUs.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3353-L3381

> diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
> index f75659fff2874..596431b00a03e 100644
> --- a/drivers/soc/qcom/spm.c
> +++ b/drivers/soc/qcom/spm.c

[ ... ]

> @@ -501,6 +517,8 @@ static const struct of_device_id spm_match_table[] = {
>  	  .data = &spm_reg_8974_8084_cpu },
>  	{ .compatible = "qcom,apq8064-saw2-v1.1-cpu",
>  	  .data = &spm_reg_8064_cpu },
> +	{ .compatible = "qcom,msm8960-saw2-v1.1-cpu",
> +	  .data = &spm_reg_8960_cpu },

Will adding this compatible trigger a division by zero during device probe?

While this issue wasn't introduced by this patch, probing this device reveals
a division by zero in spm_register_regulator() when computing drv->volt_sel:

drivers/soc/qcom/spm.c:spm_register_regulator() {
    ...
	rdesc = devm_kzalloc(dev, sizeof(*rdesc), GFP_KERNEL);
	if (!rdesc)
		return -ENOMEM;
    ...
	drv->volt_sel = DIV_ROUND_UP(drv->reg_data->init_uV - rdesc->min_uV,
				     rdesc->uV_step);
    ...
}

Because rdesc is allocated using devm_kzalloc(), all of its fields are zero.

Since rdesc->uV_step is never explicitly initialized before this operation,
does it remain 0, causing a panic?

The subsequent call to linear_range_get_selector_high() correctly computes
the selector and overwrites drv->volt_sel.

Is it possible that the older DIV_ROUND_UP() calculation was left in place
by mistake and needs to be removed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-expressatt_cpufreq-v1-0-487fd2d78859@gmail.com?part=2

Re: [PATCH 3/3] ARM: dts: qcom: msm8960: Add CPU frequency scaling support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `opp-supported-hw` property specifies an array of three all-1s masks, misusing the OPP core API and completely bypassing hardware speed bin filtering.
- [Medium] The commit implicitly corrects the `saw0` and `saw1` compatible strings without documenting this behavioral change in the commit message.
- [Low] The newly added properties `opp-microvolt-speed0-pvs0-v0` (and similar `-v0` properties) violate the device tree binding schema and will cause `make dt_binding_check` to fail.
--

commit 06323598829c4bb247922fa2b1d518f8024bc3f5
Author: Rudraksha Gupta <guptarud@gmail.com>

ARM: dts: qcom: msm8960: Add CPU frequency scaling support

Enable Krait DVFS on MSM8960 by adding the required device tree nodes:

- OPP table with 12 operating points from 384 MHz to 1.512 GHz, with
  per-PVS voltages for slow, nominal, and fast silicon bins.
- Krait clock controller (krait-cc-v1) driving the CPU muxes from
  PLL9/PLL10, ACC aux outputs, and PXO.
- PVS efuse nvmem cell in qfprom for the cpufreq-nvmem driver to
  read the speed-bin and process voltage class.
- CPU idle state for Standalone Power Collapse (SPC).
- operating-points-v2, clocks, cpu-supply, and cpu-idle-states wired
  into both CPU nodes.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/acpuclock-8960.c#L120-L235

> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> index fd28401cebb5e..50e51021e2d7c 100644
> --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi

[ ... ]

> +	cpu_opp_table: opp-table-cpu {
> +		compatible = "operating-points-v2-krait-cpu";
> +		nvmem-cells = <&pvs_efuse>;
> +
> +		opp-384000000 {
> +			opp-hz = /bits/ 64 <384000000>;
> +			opp-microvolt-speed0-pvs0-v0 = <950000>;

Does the opp-v2-kryo-cpu.yaml binding schema support this -v0 suffix?

The schema currently restricts microvolt property names using the regex
pattern ^opp-microvolt-speed[0-9]+-pvs[0-9]+$ and enforces
additionalProperties: false for OPP nodes.

Appending the -v0 suffix here will likely cause dtbs_check to reject it as
an undocumented property, introducing a schema validation regression.

> +			opp-microvolt-speed0-pvs1-v0 = <900000>;
> +			opp-microvolt-speed0-pvs3-v0 = <850000>;
> +			opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF>;

Is this opp-supported-hw mask configured correctly?

The qcom-cpufreq-nvmem driver configures the OPP core to expect a single
32-bit hardware version mask (config.supported_hw_count = 1). In
drivers/opp/of.c:_read_supported_hw(), having three elements is interpreted as
three separate hardware versions.

Because every mask has all bits set to 1, the validation check
(val & drv->versions) will always evaluate to true, bypassing the
hardware speed bin filtering. If a chip evaluates to a higher speed bin (e.g.,
speed1), the OPP core will register these operating points but fail to find the
corresponding voltage properties, as only speed0 voltages are defined here.

Will this scale the CPU clock without appropriately scaling its voltage supply?

Should this be a single 32-bit mask representing the supported speed bin (e.g.,
<0x1> for speed0)?

> +		};

[ ... ]

>  		saw0: power-manager@2089000 {
> -			compatible = "qcom,msm8960-saw2-cpu", "qcom,saw2";
> +			compatible = "qcom,msm8960-saw2-v1.1-cpu", "qcom,saw2";

This isn't a bug, but this compatible string change isn't mentioned in the
commit message.

Since this alters the SPM node compatible strings and is functionally required
for the newly introduced cpu_spc idle state, could this correction be
documented in the commit message?

>  			reg = <0x02089000 0x1000>, <0x02009000 0x1000>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-expressatt_cpufreq-v1-0-487fd2d78859@gmail.com?part=3