[PATCH v2 0/3] Add cpufreq to MSM8960

[PATCH v2 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>
---
Changes in v2:
- undo saw2 compatible rename
- update dts schema
- formatting
- Link to v1: https://lore.kernel.org/r/20260514-expressatt_cpufreq-v1-0-487fd2d78859@gmail.com

---
Rudraksha Gupta (3):
      dt-bindings: opp: Allow optional -vN suffix in opp-microvolt property name
      soc: qcom: spm: Add MSM8960 SAW2 CPU support
      ARM: dts: qcom: msm8960: Add CPU frequency scaling support

 .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml   |   2 +-
 arch/arm/boot/dts/qcom/qcom-msm8960.dtsi           | 129 +++++++++++++++++++++
 drivers/soc/qcom/spm.c                             |  20 +++-
 3 files changed, 149 insertions(+), 2 deletions(-)
---
base-commit: 3131ff5a117498bb4b9db3a238bb311cbf8383ce
change-id: 20260513-expressatt_cpufreq-66638ba8d156
prerequisite-message-id: <20260527-expressatt-touchkey-v2-1-049dca41fc3a@gmail.com>
prerequisite-patch-id: 2b24e9ba47500ef05d38e37b40d8ca2dceb4716a
prerequisite-message-id: <20260527-expressatt_camera_flash-v6-0-de0f150024e4@gmail.com>
prerequisite-patch-id: ab8b8d87fd2d518c4c5b5dace3f22238d1abbe49
prerequisite-patch-id: 466e1f74760f1a5ba7c222d01953aed6ea787390
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 v2 1/3] dt-bindings: opp: Allow optional -vN suffix in opp-microvolt property name

[Rudraksha Gupta via B4 Relay]

From: Rudraksha Gupta <guptarud@gmail.com>

The qcom-cpufreq-nvmem driver generates prop_name as
"speed%d-pvs%d-v%d" for Krait SoCs, resulting in property names like
opp-microvolt-speed0-pvs0-v0. The existing schema regex only allows
opp-microvolt-speed[0-9]+-pvs[0-9]+ without the trailing version
suffix.

Extend the regex to optionally match a -v[0-9]+ suffix so that
devicetrees using the full prop_name pass schema validation.

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

diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
index fd04d060c1de..846f49a99484 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
@@ -81,7 +81,7 @@ patternProperties:
       required-opps: true
 
     patternProperties:
-      '^opp-microvolt-speed[0-9]+-pvs[0-9]+$': true
+      '^opp-microvolt-speed[0-9]+-pvs[0-9]+(-v[0-9]+)?$': true
 
     required:
       - opp-hz

-- 
2.54.0

Re: [PATCH v2 1/3] dt-bindings: opp: Allow optional -vN suffix in opp-microvolt property name

[Dmitry Baryshkov]

On Wed, May 27, 2026 at 08:39:28PM -0700, Rudraksha Gupta wrote:
> The qcom-cpufreq-nvmem driver generates prop_name as
> "speed%d-pvs%d-v%d" for Krait SoCs, resulting in property names like
> opp-microvolt-speed0-pvs0-v0. The existing schema regex only allows
> opp-microvolt-speed[0-9]+-pvs[0-9]+ without the trailing version
> suffix.
> 
> Extend the regex to optionally match a -v[0-9]+ suffix so that
> devicetrees using the full prop_name pass schema validation.
> 
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
>  Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> index fd04d060c1de..846f49a99484 100644
> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> @@ -81,7 +81,7 @@ patternProperties:
>        required-opps: true
>  
>      patternProperties:
> -      '^opp-microvolt-speed[0-9]+-pvs[0-9]+$': true
> +      '^opp-microvolt-speed[0-9]+-pvs[0-9]+(-v[0-9]+)?$': true

I think this should be fixed differently. There is no version for
MSM8960 / APQ8064, per design. It is only applicable to MSM8974 /
APQ8084. You also need to scale the core voltages.  Would you consider
picking up the relevant parts of [1]? (also see [2] and [3])?

I got stuck because I couldn't implement L2 plumbing properly and never
pushed the series further. On both MSM8960 and APQ8064 we can scale L2
cache to follow the CPU frequency. I tried adding the driver for it, but
RobH requested using cpu_subsys, but there each cache device gets
created multiple times. Maybe I should fix that in the end, then we can
scale the L2 too.

[1] https://lore.kernel.org/linux-arm-msm/20231002185940.1271800-1-dmitry.baryshkov@linaro.org/

[2] https://lore.kernel.org/linux-arm-msm/20230827115033.935089-1-dmitry.baryshkov@linaro.org/

[3] https://lore.kernel.org/linux-arm-msm/20230702175045.122041-1-dmitry.baryshkov@linaro.org/

-- 
With best wishes
Dmitry

[PATCH v2 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.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3265-L3285
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..fb3ec8aa42b0 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-cpu",
+	  .data = &spm_reg_8960_cpu },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, spm_match_table);

-- 
2.54.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unconditional division by zero during regulator registration
- [High] Infinite polling loop in hardware register write sequence
--

commit 17a126a384bb63507998b0691e4ff49e0de54dab
Author: Rudraksha Gupta <guptarud@gmail.com>

soc: qcom: spm: Add MSM8960 SAW2 CPU support

This commit adds SPM register data for the MSM8960 CPU. It configures the SPM
sequences, PMIC delays, and regulator ranges to support the SAW2 v1.1 hardware
present in this SoC.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3265-L3285
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..fb3ec8aa42b07 100644
> --- a/drivers/soc/qcom/spm.c
> +++ b/drivers/soc/qcom/spm.c
> @@ -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,

[Severity: High]
This isn't a regression introduced by this patch, but registering these
offsets enables a code path with an unbounded polling loop.

During probe, setting up the default low power mode eventually calls
spm_register_write_sync():

drivers/soc/qcom/spm.c:spm_register_write_sync() {
	...
	do {
		writel_relaxed(val, drv->reg_base +
				drv->reg_data->reg_offset[reg]);
		ret = readl_relaxed(drv->reg_base +
				drv->reg_data->reg_offset[reg]);
		if (ret == val)
			break;
		cpu_relax();
	} while (1);
}

If the hardware is in an invalid state, or if certain register bits are
read-only and fail to reflect the written toggle, could this loop hang
indefinitely?

Would it be safer to use a proper timeout mechanism like
read_poll_timeout_atomic() here to allow for graceful recovery?

> +	.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,

[Severity: Critical]
This is a pre-existing issue, but I noticed that setting init_uV here
triggers a division by zero during probe.

When spm_register_regulator() allocates rdesc via devm_kzalloc(),
rdesc->uV_step is zero-initialized and never explicitly set. Later, it
performs this calculation:

drivers/soc/qcom/spm.c:spm_register_regulator() {
	...
	drv->volt_sel = DIV_ROUND_UP(drv->reg_data->init_uV - rdesc->min_uV,
				     rdesc->uV_step);
	...
}

Will this result in an unconditional division by zero when calculating
drv->volt_sel?

> +	.ramp_delay = 1250,
> +};
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527-expressatt_cpufreq-v2-0-b9b7726ccb6d@gmail.com?part=2

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

[Dmitry Baryshkov]

On Wed, May 27, 2026 at 08:39:29PM -0700, Rudraksha Gupta via B4 Relay wrote:
> 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.
> 
> Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3265-L3285
> 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..fb3ec8aa42b0 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,

Except for this value, the programming is the same as the existing
APQ8064. But, APQ8064 seems to have an error there, it also should be
using this pmic_dly.

But#2, both APQ8064 and MSM8960 should only be using this table for the
SAW2 of the first CPU core. The rest should be using a slightly
different config (at least according to msm-3.4 tree I'm looking at).
Would you please fix that?

Please make existing APQ8064 entry use pmic_dly of 0x03020004, use it
for 8960 too. Then add new compat (something like
qcom,apq8064-saw2-v1.1-secondary) and use it for the CPU 1-3 on APQ8064
and similarly qcom,msm8960-saw2-secondary for CPU1 on MSM8960. Feel free
to propose a better name.

> +	.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-cpu",
> +	  .data = &spm_reg_8960_cpu },
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(of, spm_match_table);
> 
> -- 
> 2.54.0
> 
> 

-- 
With best wishes
Dmitry

[PATCH v2 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
Tested-by: Antony Kurniawan Soemardi <linux@smankusors.com>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 129 +++++++++++++++++++++++++++++++
 1 file changed, 129 insertions(+)

diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index a427f0f41cd1..3bb78a704850 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,123 @@ 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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+
+		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 = <0x1>;
+		};
+	};
+
+	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>;
 	};
 
 	memory@80000000 {
@@ -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>;
 			};

-- 
2.54.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The Krait CPU frequency nvmem parsing functions incorrectly cast a `u8 *` buffer directly to a `u32 *` to read the efuse registers, leading to endianness issues on big-endian systems.
--

commit dde749d736e7e3301796875cc37f978b7980ba69
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 for
the OPP table, Krait clock controller, PVS efuse nvmem cell, and CPU idle
state.

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..d4f4681974c5a 100644
> --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi

[ ... ]

> @@ -74,6 +82,123 @@ 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>;

[Severity: High]
This is a pre-existing issue, but does reading this efuse have an endianness
problem in the driver?

Looking at get_krait_bin_format_a() and get_krait_bin_format_b() in
drivers/cpufreq/qcom-cpufreq-nvmem.c, the code casts the u8 * buffer directly
to a u32 * to read the efuse registers, rather than using endian-safe
accessors like get_unaligned_le32().

On big-endian systems, would this read the nvmem data in reversed byte order,
resulting in incorrect speed and PVS bins being extracted and potentially
causing over or under-voltage issues by selecting the wrong operating points?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527-expressatt_cpufreq-v2-0-b9b7726ccb6d@gmail.com?part=3