linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186
@ 2022-04-15  5:59 Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 01/15] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property Rex-BC Chen
                   ` (14 more replies)
  0 siblings, 15 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

Cpufreq is a DVFS driver used for power saving to scale the clock frequency
and supply the voltage for CPUs. This series do some cleanup for MediaTek
cpufreq drivers and add support for MediaTek SVS[2] and MediaTek CCI
devfreq[3] which are supported in MT8183 and MT8186.

Changes for V3:
1. Rebased to linux-next-20220414.
2. Drop accepted patches.
3. Drop "cpufreq: mediatek: Use maximum voltage in init stage" because we
   make sure the voltage we set is safe for both mediatek cci and cpufreq.
4. Rename cci property to mediatek,cci.
5. Adjust order of cleanup patches.
6. Add new patches for cleanup, handle infinite loop and MT8183 dts.
7. Revise drivers from reviewers' suggestion.
8. Revise commit message of some patches to avoid confusion and misunderstand.
9. Revise "cpufreq: mediatek: Link CCI device to CPU".
   We do not return successful to pretend we set the target frequency done
   when cci is not ready. Instead, we find and set a safe voltage so that we
   can set the target cpufrequency.

Changes for V2:
1. Drop the modification of transforming cpufreq-mediatek into yaml and
   only add the MediaTek CCI property for MediaTek cpufreq.
2. Split the original patches into several patches.

Reference series:
[1]: V1 of this series is present by Jia-Wei Chang.
     message-id:20220307122151.11666-1-jia-wei.chang@mediatek.com

[2]: The MediaTek CCI devfreq driver is introduced in another series.
     message-id:20220408052150.22536-1-johnson.wang@mediatek.com

[3]: The MediaTek SVS driver is introduced in another series.
     message-id:20220221063939.14969-1-roger.lu@mediatek.com

Andrew-sh.Cheng (1):
  cpufreq: mediatek: Add opp notification support

Jia-Wei Chang (8):
  dt-bindings: cpufreq: mediatek: Add MediaTek CCI property
  cpufreq: mediatek: Record previous target vproc value
  cpufreq: mediatek: Move voltage limits to platform data
  cpufreq: mediatek: Add .get function
  cpufreq: mediatek: Make sram regulator optional
  cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()
  cpufreq: mediatek: Link CCI device to CPU
  cpufreq: mediatek: Add support for MT8186

Rex-BC Chen (6):
  cpufreq: mediatek: Use device print to show logs
  cpufreq: mediatek: Replace old_* with pre_*
  cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq
  arm64: dts: mediatek: Add MediaTek CCI node for MT8183
  arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq

 .../bindings/cpufreq/cpufreq-mediatek.txt     |   5 +
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |  36 ++
 .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   4 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 285 ++++++++++
 drivers/cpufreq/mediatek-cpufreq.c            | 497 ++++++++++++------
 5 files changed, 664 insertions(+), 163 deletions(-)

-- 
2.18.0


^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH V3 01/15] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs Rex-BC Chen
                   ` (13 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

MediaTek Cache Coherent Interconnect (CCI) uses software devfreq module
to scale the clock frequency and adjust the voltage.
The phandle could be linked between CPU and MediaTek CCI for some
MediaTek SoCs, like MT8183 and MT8186.
Therefore, we add this property in cpufreq-mediatek.txt.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 .../devicetree/bindings/cpufreq/cpufreq-mediatek.txt         | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
index b8233ec91d3d..5b1558f220ac 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
@@ -20,6 +20,11 @@ Optional properties:
 	       Vsram to fit SoC specific needs. When absent, the voltage scaling
 	       flow is handled by hardware, hence no software "voltage tracking" is
 	       needed.
+- mediatek,cci:
+	MediaTek Cache Coherent Interconnect (CCI) uses the software devfreq module to
+	scale the clock frequency and adjust the voltage.
+	For details, please refer to
+	Documentation/devicetree/bindings/arm/mediatek/mediatek,cci.yaml
 - #cooling-cells:
 	For details, please refer to
 	Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 01/15] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_* Rex-BC Chen
                   ` (12 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

- Replace pr_* with dev_* to show logs.
- Remove usage of __func__.

Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 54 ++++++++++++++++--------------
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index dc4a87e68940..e040f3574af9 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -65,7 +65,8 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 
 	old_vproc = regulator_get_voltage(proc_reg);
 	if (old_vproc < 0) {
-		pr_err("%s: invalid Vproc value: %d\n", __func__, old_vproc);
+		dev_err(info->cpu_dev,
+			"invalid Vproc value: %d\n", old_vproc);
 		return old_vproc;
 	}
 	/* Vsram should not exceed the maximum allowed voltage of SoC. */
@@ -81,14 +82,14 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 		do {
 			old_vsram = regulator_get_voltage(sram_reg);
 			if (old_vsram < 0) {
-				pr_err("%s: invalid Vsram value: %d\n",
-				       __func__, old_vsram);
+				dev_err(info->cpu_dev,
+					"invalid Vsram value: %d\n", old_vsram);
 				return old_vsram;
 			}
 			old_vproc = regulator_get_voltage(proc_reg);
 			if (old_vproc < 0) {
-				pr_err("%s: invalid Vproc value: %d\n",
-				       __func__, old_vproc);
+				dev_err(info->cpu_dev,
+					"invalid Vproc value: %d\n", old_vproc);
 				return old_vproc;
 			}
 
@@ -136,14 +137,14 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 		do {
 			old_vproc = regulator_get_voltage(proc_reg);
 			if (old_vproc < 0) {
-				pr_err("%s: invalid Vproc value: %d\n",
-				       __func__, old_vproc);
+				dev_err(info->cpu_dev,
+					"invalid Vproc value: %d\n", old_vproc);
 				return old_vproc;
 			}
 			old_vsram = regulator_get_voltage(sram_reg);
 			if (old_vsram < 0) {
-				pr_err("%s: invalid Vsram value: %d\n",
-				       __func__, old_vsram);
+				dev_err(info->cpu_dev,
+					"invalid Vsram value: %d\n", old_vsram);
 				return old_vsram;
 			}
 
@@ -214,7 +215,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	old_freq_hz = clk_get_rate(cpu_clk);
 	old_vproc = regulator_get_voltage(info->proc_reg);
 	if (old_vproc < 0) {
-		pr_err("%s: invalid Vproc value: %d\n", __func__, old_vproc);
+		dev_err(cpu_dev, "invalid Vproc value: %d\n", old_vproc);
 		return old_vproc;
 	}
 
@@ -222,8 +223,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 
 	opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_hz);
 	if (IS_ERR(opp)) {
-		pr_err("cpu%d: failed to find OPP for %ld\n",
-		       policy->cpu, freq_hz);
+		dev_err(cpu_dev, "cpu%d: failed to find OPP for %ld\n",
+			policy->cpu, freq_hz);
 		return PTR_ERR(opp);
 	}
 	vproc = dev_pm_opp_get_voltage(opp);
@@ -237,8 +238,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	if (old_vproc < target_vproc) {
 		ret = mtk_cpufreq_set_voltage(info, target_vproc);
 		if (ret) {
-			pr_err("cpu%d: failed to scale up voltage!\n",
-			       policy->cpu);
+			dev_err(cpu_dev,
+				"cpu%d: failed to scale up voltage!\n", policy->cpu);
 			mtk_cpufreq_set_voltage(info, old_vproc);
 			return ret;
 		}
@@ -247,8 +248,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	/* Reparent the CPU clock to intermediate clock. */
 	ret = clk_set_parent(cpu_clk, info->inter_clk);
 	if (ret) {
-		pr_err("cpu%d: failed to re-parent cpu clock!\n",
-		       policy->cpu);
+		dev_err(cpu_dev,
+			"cpu%d: failed to re-parent cpu clock!\n", policy->cpu);
 		mtk_cpufreq_set_voltage(info, old_vproc);
 		WARN_ON(1);
 		return ret;
@@ -257,8 +258,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	/* Set the original PLL to target rate. */
 	ret = clk_set_rate(armpll, freq_hz);
 	if (ret) {
-		pr_err("cpu%d: failed to scale cpu clock rate!\n",
-		       policy->cpu);
+		dev_err(cpu_dev,
+			"cpu%d: failed to scale cpu clock rate!\n", policy->cpu);
 		clk_set_parent(cpu_clk, armpll);
 		mtk_cpufreq_set_voltage(info, old_vproc);
 		return ret;
@@ -267,8 +268,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	/* Set parent of CPU clock back to the original PLL. */
 	ret = clk_set_parent(cpu_clk, armpll);
 	if (ret) {
-		pr_err("cpu%d: failed to re-parent cpu clock!\n",
-		       policy->cpu);
+		dev_err(cpu_dev,
+			"cpu%d: failed to re-parent cpu clock!\n", policy->cpu);
 		mtk_cpufreq_set_voltage(info, inter_vproc);
 		WARN_ON(1);
 		return ret;
@@ -281,8 +282,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	if (vproc < inter_vproc || vproc < old_vproc) {
 		ret = mtk_cpufreq_set_voltage(info, vproc);
 		if (ret) {
-			pr_err("cpu%d: failed to scale down voltage!\n",
-			       policy->cpu);
+			dev_err(cpu_dev,
+				"cpu%d: failed to scale down voltage!\n", policy->cpu);
 			clk_set_parent(cpu_clk, info->inter_clk);
 			clk_set_rate(armpll, old_freq_hz);
 			clk_set_parent(cpu_clk, armpll);
@@ -448,15 +449,16 @@ static int mtk_cpufreq_init(struct cpufreq_policy *policy)
 
 	info = mtk_cpu_dvfs_info_lookup(policy->cpu);
 	if (!info) {
-		pr_err("dvfs info for cpu%d is not initialized.\n",
-		       policy->cpu);
+		dev_err(info->cpu_dev,
+			"dvfs info for cpu%d is not initialized.\n", policy->cpu);
 		return -EINVAL;
 	}
 
 	ret = dev_pm_opp_init_cpufreq_table(info->cpu_dev, &freq_table);
 	if (ret) {
-		pr_err("failed to init cpufreq table for cpu%d: %d\n",
-		       policy->cpu, ret);
+		dev_err(info->cpu_dev,
+			"failed to init cpufreq table for cpu%d: %d\n",
+			policy->cpu, ret);
 		return ret;
 	}
 
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_*
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 01/15] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value Rex-BC Chen
                   ` (11 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

To make driver more readable, replace old_* with pre_*.

Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 84 +++++++++++++++---------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index e040f3574af9..ff27f77e8ee6 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -61,18 +61,18 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 {
 	struct regulator *proc_reg = info->proc_reg;
 	struct regulator *sram_reg = info->sram_reg;
-	int old_vproc, old_vsram, new_vsram, vsram, vproc, ret;
+	int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
 
-	old_vproc = regulator_get_voltage(proc_reg);
-	if (old_vproc < 0) {
+	pre_vproc = regulator_get_voltage(proc_reg);
+	if (pre_vproc < 0) {
 		dev_err(info->cpu_dev,
-			"invalid Vproc value: %d\n", old_vproc);
-		return old_vproc;
+			"invalid Vproc value: %d\n", pre_vproc);
+		return pre_vproc;
 	}
 	/* Vsram should not exceed the maximum allowed voltage of SoC. */
 	new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT);
 
-	if (old_vproc < new_vproc) {
+	if (pre_vproc < new_vproc) {
 		/*
 		 * When scaling up voltages, Vsram and Vproc scale up step
 		 * by step. At each step, set Vsram to (Vproc + 200mV) first,
@@ -80,20 +80,20 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 		 * Keep doing it until Vsram and Vproc hit target voltages.
 		 */
 		do {
-			old_vsram = regulator_get_voltage(sram_reg);
-			if (old_vsram < 0) {
+			pre_vsram = regulator_get_voltage(sram_reg);
+			if (pre_vsram < 0) {
 				dev_err(info->cpu_dev,
-					"invalid Vsram value: %d\n", old_vsram);
-				return old_vsram;
+					"invalid Vsram value: %d\n", pre_vsram);
+				return pre_vsram;
 			}
-			old_vproc = regulator_get_voltage(proc_reg);
-			if (old_vproc < 0) {
+			pre_vproc = regulator_get_voltage(proc_reg);
+			if (pre_vproc < 0) {
 				dev_err(info->cpu_dev,
-					"invalid Vproc value: %d\n", old_vproc);
-				return old_vproc;
+					"invalid Vproc value: %d\n", pre_vproc);
+				return pre_vproc;
 			}
 
-			vsram = min(new_vsram, old_vproc + MAX_VOLT_SHIFT);
+			vsram = min(new_vsram, pre_vproc + MAX_VOLT_SHIFT);
 
 			if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) {
 				vsram = MAX_VOLT_LIMIT;
@@ -122,12 +122,12 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 			ret = regulator_set_voltage(proc_reg, vproc,
 						    vproc + VOLT_TOL);
 			if (ret) {
-				regulator_set_voltage(sram_reg, old_vsram,
-						      old_vsram);
+				regulator_set_voltage(sram_reg, pre_vsram,
+						      pre_vsram);
 				return ret;
 			}
 		} while (vproc < new_vproc || vsram < new_vsram);
-	} else if (old_vproc > new_vproc) {
+	} else if (pre_vproc > new_vproc) {
 		/*
 		 * When scaling down voltages, Vsram and Vproc scale down step
 		 * by step. At each step, set Vproc to (Vsram - 200mV) first,
@@ -135,20 +135,20 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 		 * Keep doing it until Vsram and Vproc hit target voltages.
 		 */
 		do {
-			old_vproc = regulator_get_voltage(proc_reg);
-			if (old_vproc < 0) {
+			pre_vproc = regulator_get_voltage(proc_reg);
+			if (pre_vproc < 0) {
 				dev_err(info->cpu_dev,
-					"invalid Vproc value: %d\n", old_vproc);
-				return old_vproc;
+					"invalid Vproc value: %d\n", pre_vproc);
+				return pre_vproc;
 			}
-			old_vsram = regulator_get_voltage(sram_reg);
-			if (old_vsram < 0) {
+			pre_vsram = regulator_get_voltage(sram_reg);
+			if (pre_vsram < 0) {
 				dev_err(info->cpu_dev,
-					"invalid Vsram value: %d\n", old_vsram);
-				return old_vsram;
+					"invalid Vsram value: %d\n", pre_vsram);
+				return pre_vsram;
 			}
 
-			vproc = max(new_vproc, old_vsram - MAX_VOLT_SHIFT);
+			vproc = max(new_vproc, pre_vsram - MAX_VOLT_SHIFT);
 			ret = regulator_set_voltage(proc_reg, vproc,
 						    vproc + VOLT_TOL);
 			if (ret)
@@ -178,8 +178,8 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 			}
 
 			if (ret) {
-				regulator_set_voltage(proc_reg, old_vproc,
-						      old_vproc);
+				regulator_set_voltage(proc_reg, pre_vproc,
+						      pre_vproc);
 				return ret;
 			}
 		} while (vproc > new_vproc + VOLT_TOL ||
@@ -207,16 +207,16 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	struct mtk_cpu_dvfs_info *info = policy->driver_data;
 	struct device *cpu_dev = info->cpu_dev;
 	struct dev_pm_opp *opp;
-	long freq_hz, old_freq_hz;
-	int vproc, old_vproc, inter_vproc, target_vproc, ret;
+	long freq_hz, pre_freq_hz;
+	int vproc, pre_vproc, inter_vproc, target_vproc, ret;
 
 	inter_vproc = info->intermediate_voltage;
 
-	old_freq_hz = clk_get_rate(cpu_clk);
-	old_vproc = regulator_get_voltage(info->proc_reg);
-	if (old_vproc < 0) {
-		dev_err(cpu_dev, "invalid Vproc value: %d\n", old_vproc);
-		return old_vproc;
+	pre_freq_hz = clk_get_rate(cpu_clk);
+	pre_vproc = regulator_get_voltage(info->proc_reg);
+	if (pre_vproc < 0) {
+		dev_err(cpu_dev, "invalid Vproc value: %d\n", pre_vproc);
+		return pre_vproc;
 	}
 
 	freq_hz = freq_table[index].frequency * 1000;
@@ -235,12 +235,12 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	 * current voltage, scale up voltage first.
 	 */
 	target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
-	if (old_vproc < target_vproc) {
+	if (pre_vproc < target_vproc) {
 		ret = mtk_cpufreq_set_voltage(info, target_vproc);
 		if (ret) {
 			dev_err(cpu_dev,
 				"cpu%d: failed to scale up voltage!\n", policy->cpu);
-			mtk_cpufreq_set_voltage(info, old_vproc);
+			mtk_cpufreq_set_voltage(info, pre_vproc);
 			return ret;
 		}
 	}
@@ -250,7 +250,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	if (ret) {
 		dev_err(cpu_dev,
 			"cpu%d: failed to re-parent cpu clock!\n", policy->cpu);
-		mtk_cpufreq_set_voltage(info, old_vproc);
+		mtk_cpufreq_set_voltage(info, pre_vproc);
 		WARN_ON(1);
 		return ret;
 	}
@@ -261,7 +261,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 		dev_err(cpu_dev,
 			"cpu%d: failed to scale cpu clock rate!\n", policy->cpu);
 		clk_set_parent(cpu_clk, armpll);
-		mtk_cpufreq_set_voltage(info, old_vproc);
+		mtk_cpufreq_set_voltage(info, pre_vproc);
 		return ret;
 	}
 
@@ -279,13 +279,13 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	 * If the new voltage is lower than the intermediate voltage or the
 	 * original voltage, scale down to the new voltage.
 	 */
-	if (vproc < inter_vproc || vproc < old_vproc) {
+	if (vproc < inter_vproc || vproc < pre_vproc) {
 		ret = mtk_cpufreq_set_voltage(info, vproc);
 		if (ret) {
 			dev_err(cpu_dev,
 				"cpu%d: failed to scale down voltage!\n", policy->cpu);
 			clk_set_parent(cpu_clk, info->inter_clk);
-			clk_set_rate(armpll, old_freq_hz);
+			clk_set_rate(armpll, pre_freq_hz);
 			clk_set_parent(cpu_clk, armpll);
 			return ret;
 		}
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (2 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_* Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data Rex-BC Chen
                   ` (10 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng,
	Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

We found the buck voltage may not be exactly the same with what we set
because CPU may share the same buck with other module.
Therefore, we need to record the previous desired value instead of reading
it from regulators.

Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index ff27f77e8ee6..fa8b193bf27b 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -40,6 +40,7 @@ struct mtk_cpu_dvfs_info {
 	struct list_head list_head;
 	int intermediate_voltage;
 	bool need_voltage_tracking;
+	int pre_vproc;
 };
 
 static LIST_HEAD(dvfs_info_list);
@@ -191,11 +192,17 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 
 static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc)
 {
+	int ret;
+
 	if (info->need_voltage_tracking)
-		return mtk_cpufreq_voltage_tracking(info, vproc);
+		ret = mtk_cpufreq_voltage_tracking(info, vproc);
 	else
-		return regulator_set_voltage(info->proc_reg, vproc,
-					     vproc + VOLT_TOL);
+		ret = regulator_set_voltage(info->proc_reg, vproc,
+					    MAX_VOLT_LIMIT);
+	if (!ret)
+		info->pre_vproc = vproc;
+
+	return ret;
 }
 
 static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
@@ -213,7 +220,9 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	inter_vproc = info->intermediate_voltage;
 
 	pre_freq_hz = clk_get_rate(cpu_clk);
-	pre_vproc = regulator_get_voltage(info->proc_reg);
+	pre_vproc = info->pre_vproc;
+	if (pre_vproc <= 0)
+		pre_vproc = regulator_get_voltage(info->proc_reg);
 	if (pre_vproc < 0) {
 		dev_err(cpu_dev, "invalid Vproc value: %d\n", pre_vproc);
 		return pre_vproc;
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (3 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 07/15] cpufreq: mediatek: Add .get function Rex-BC Chen
                   ` (9 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

Voltages and shifts are defined as macros originally.
There are different requirements of these values for each MediaTek SoCs.
Therefore, we add the platform data and move these values into it.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 90 ++++++++++++++++++++----------
 1 file changed, 61 insertions(+), 29 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index 221f249f8d21..ebc4bfd66ad5 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -10,15 +10,21 @@
 #include <linux/cpumask.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/pm_opp.h>
 #include <linux/regulator/consumer.h>
 
-#define MIN_VOLT_SHIFT		(100000)
-#define MAX_VOLT_SHIFT		(200000)
-#define MAX_VOLT_LIMIT		(1150000)
 #define VOLT_TOL		(10000)
 
+struct mtk_cpufreq_platform_data {
+	int min_volt_shift;
+	int max_volt_shift;
+	int proc_max_volt;
+	int sram_min_volt;
+	int sram_max_volt;
+};
+
 /*
  * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU DVFS
  * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
@@ -46,8 +52,11 @@ struct mtk_cpu_dvfs_info {
 	struct notifier_block opp_nb;
 	int opp_cpu;
 	unsigned long opp_freq;
+	const struct mtk_cpufreq_platform_data *soc_data;
 };
 
+static struct platform_device *cpufreq_pdev;
+
 static LIST_HEAD(dvfs_info_list);
 
 static struct mtk_cpu_dvfs_info *mtk_cpu_dvfs_info_lookup(int cpu)
@@ -65,6 +74,7 @@ static struct mtk_cpu_dvfs_info *mtk_cpu_dvfs_info_lookup(int cpu)
 static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 					int new_vproc)
 {
+	const struct mtk_cpufreq_platform_data *soc_data = info->soc_data;
 	struct regulator *proc_reg = info->proc_reg;
 	struct regulator *sram_reg = info->sram_reg;
 	int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
@@ -76,7 +86,8 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 		return pre_vproc;
 	}
 	/* Vsram should not exceed the maximum allowed voltage of SoC. */
-	new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT);
+	new_vsram = min(new_vproc + soc_data->min_volt_shift,
+			soc_data->sram_max_volt);
 
 	if (pre_vproc < new_vproc) {
 		/*
@@ -99,10 +110,11 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 				return pre_vproc;
 			}
 
-			vsram = min(new_vsram, pre_vproc + MAX_VOLT_SHIFT);
+			vsram = min(new_vsram,
+				    pre_vproc + soc_data->min_volt_shift);
 
-			if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) {
-				vsram = MAX_VOLT_LIMIT;
+			if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+				vsram = soc_data->sram_max_volt;
 
 				/*
 				 * If the target Vsram hits the maximum voltage,
@@ -120,7 +132,7 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 				ret = regulator_set_voltage(sram_reg, vsram,
 							    vsram + VOLT_TOL);
 
-				vproc = vsram - MIN_VOLT_SHIFT;
+				vproc = vsram - soc_data->min_volt_shift;
 			}
 			if (ret)
 				return ret;
@@ -154,7 +166,8 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 				return pre_vsram;
 			}
 
-			vproc = max(new_vproc, pre_vsram - MAX_VOLT_SHIFT);
+			vproc = max(new_vproc,
+				    pre_vsram - soc_data->max_volt_shift);
 			ret = regulator_set_voltage(proc_reg, vproc,
 						    vproc + VOLT_TOL);
 			if (ret)
@@ -163,10 +176,11 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 			if (vproc == new_vproc)
 				vsram = new_vsram;
 			else
-				vsram = max(new_vsram, vproc + MIN_VOLT_SHIFT);
+				vsram = max(new_vsram,
+					    vproc + soc_data->min_volt_shift);
 
-			if (vsram + VOLT_TOL >= MAX_VOLT_LIMIT) {
-				vsram = MAX_VOLT_LIMIT;
+			if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+				vsram = soc_data->sram_max_volt;
 
 				/*
 				 * If the target Vsram hits the maximum voltage,
@@ -197,13 +211,14 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 
 static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc)
 {
+	const struct mtk_cpufreq_platform_data *soc_data = info->soc_data;
 	int ret;
 
 	if (info->need_voltage_tracking)
 		ret = mtk_cpufreq_voltage_tracking(info, vproc);
 	else
 		ret = regulator_set_voltage(info->proc_reg, vproc,
-					    MAX_VOLT_LIMIT);
+					    soc_data->proc_max_volt);
 	if (!ret)
 		info->pre_vproc = vproc;
 
@@ -581,9 +596,17 @@ static struct cpufreq_driver mtk_cpufreq_driver = {
 
 static int mtk_cpufreq_probe(struct platform_device *pdev)
 {
+	const struct of_device_id *match;
 	struct mtk_cpu_dvfs_info *info, *tmp;
 	int cpu, ret;
 
+	match = dev_get_platdata(&pdev->dev);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev,
+			"failed to get mtk cpufreq platform data\n");
+		return -ENODEV;
+	}
+
 	for_each_possible_cpu(cpu) {
 		info = mtk_cpu_dvfs_info_lookup(cpu);
 		if (info)
@@ -595,6 +618,7 @@ static int mtk_cpufreq_probe(struct platform_device *pdev)
 			goto release_dvfs_info_list;
 		}
 
+		info->soc_data = match->data;
 		ret = mtk_cpu_dvfs_info_init(info, cpu);
 		if (ret) {
 			dev_err(&pdev->dev,
@@ -630,20 +654,27 @@ static struct platform_driver mtk_cpufreq_platdrv = {
 	.probe		= mtk_cpufreq_probe,
 };
 
+static const struct mtk_cpufreq_platform_data mt2701_platform_data = {
+	.min_volt_shift = 100000,
+	.max_volt_shift = 200000,
+	.proc_max_volt = 1150000,
+	.sram_min_volt = 0,
+	.sram_max_volt = 1150000,
+};
+
 /* List of machines supported by this driver */
 static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
-	{ .compatible = "mediatek,mt2701", },
-	{ .compatible = "mediatek,mt2712", },
-	{ .compatible = "mediatek,mt7622", },
-	{ .compatible = "mediatek,mt7623", },
-	{ .compatible = "mediatek,mt8167", },
-	{ .compatible = "mediatek,mt817x", },
-	{ .compatible = "mediatek,mt8173", },
-	{ .compatible = "mediatek,mt8176", },
-	{ .compatible = "mediatek,mt8183", },
-	{ .compatible = "mediatek,mt8365", },
-	{ .compatible = "mediatek,mt8516", },
-
+	{ .compatible = "mediatek,mt2701", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt2712", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt7622", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt7623", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8167", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt817x", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8173", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8176", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8183", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8365", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8516", .data = &mt2701_platform_data },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, mtk_cpufreq_machines);
@@ -652,7 +683,6 @@ static int __init mtk_cpufreq_driver_init(void)
 {
 	struct device_node *np;
 	const struct of_device_id *match;
-	struct platform_device *pdev;
 	int err;
 
 	np = of_find_node_by_path("/");
@@ -676,11 +706,12 @@ static int __init mtk_cpufreq_driver_init(void)
 	 * and the device registration codes are put here to handle defer
 	 * probing.
 	 */
-	pdev = platform_device_register_simple("mtk-cpufreq", -1, NULL, 0);
-	if (IS_ERR(pdev)) {
+	cpufreq_pdev = platform_device_register_data(NULL, "mtk-cpufreq", -1,
+						     match, sizeof(*match));
+	if (IS_ERR(cpufreq_pdev)) {
 		pr_err("failed to register mtk-cpufreq platform device\n");
 		platform_driver_unregister(&mtk_cpufreq_platdrv);
-		return PTR_ERR(pdev);
+		return PTR_ERR(cpufreq_pdev);
 	}
 
 	return 0;
@@ -689,6 +720,7 @@ module_init(mtk_cpufreq_driver_init)
 
 static void __exit mtk_cpufreq_driver_exit(void)
 {
+	platform_device_unregister(cpufreq_pdev);
 	platform_driver_unregister(&mtk_cpufreq_platdrv);
 }
 module_exit(mtk_cpufreq_driver_exit)
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 07/15] cpufreq: mediatek: Add .get function
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (4 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 08/15] cpufreq: mediatek: Make sram regulator optional Rex-BC Chen
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

We want to get opp frequency via opp table. Therefore, we add the function
"mtk_cpufreq_get()" to do this.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index ebc4bfd66ad5..4d46e823c24e 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -71,6 +71,15 @@ static struct mtk_cpu_dvfs_info *mtk_cpu_dvfs_info_lookup(int cpu)
 	return NULL;
 }
 
+static unsigned int mtk_cpufreq_get(unsigned int cpu)
+{
+	struct mtk_cpu_dvfs_info *info;
+
+	info = mtk_cpu_dvfs_info_lookup(cpu);
+
+	return !info ? 0 : (info->opp_freq / 1000);
+}
+
 static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 					int new_vproc)
 {
@@ -586,7 +595,7 @@ static struct cpufreq_driver mtk_cpufreq_driver = {
 		 CPUFREQ_IS_COOLING_DEV,
 	.verify = cpufreq_generic_frequency_table_verify,
 	.target_index = mtk_cpufreq_set_target,
-	.get = cpufreq_generic_get,
+	.get = mtk_cpufreq_get,
 	.init = mtk_cpufreq_init,
 	.exit = mtk_cpufreq_exit,
 	.register_em = cpufreq_register_em_with_opp,
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 08/15] cpufreq: mediatek: Make sram regulator optional
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (5 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 07/15] cpufreq: mediatek: Add .get function Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 09/15] cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() Rex-BC Chen
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

For some MediaTek SoCs, like MT8186, it's possible that the sram regulator
is shared between CPU and CCI.
We hope regulator framework can return NULL for error handling rather
than a dummy handler from regulator_get api.
Therefore, we choose to use regulator_get_optional.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index 4d46e823c24e..559f4a383d30 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -436,7 +436,7 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
 	}
 
 	/* Both presence and absence of sram regulator are valid cases. */
-	info->sram_reg = regulator_get_exclusive(cpu_dev, "sram");
+	info->sram_reg = regulator_get_optional(cpu_dev, "sram");
 	if (IS_ERR(info->sram_reg))
 		info->sram_reg = NULL;
 	else {
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 09/15] cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (6 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 08/15] cpufreq: mediatek: Make sram regulator optional Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage Rex-BC Chen
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

Because the difference of sram and proc should in a range of min_volt_shift
and max_volt_shift. We need to adjust the sram and proc step by step.

We replace VOLT_TOL (voltage tolerance) with the platform data and update the
logic to determine the voltage boundary and invoking regulator_set_voltage.

- Use 'sram_min_volt' and 'sram_max_volt' to determine the voltage boundary
  of sram regulator.
- Use (sram_min_volt - min_volt_shift) and 'proc_max_volt' to determine the
  voltage boundary of vproc regulator.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 130 ++++++++---------------------
 1 file changed, 34 insertions(+), 96 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index 559f4a383d30..cc44a7a9427a 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -8,6 +8,7 @@
 #include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/cpumask.h>
+#include <linux/minmax.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
@@ -15,8 +16,6 @@
 #include <linux/pm_opp.h>
 #include <linux/regulator/consumer.h>
 
-#define VOLT_TOL		(10000)
-
 struct mtk_cpufreq_platform_data {
 	int min_volt_shift;
 	int max_volt_shift;
@@ -94,91 +93,44 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 			"invalid Vproc value: %d\n", pre_vproc);
 		return pre_vproc;
 	}
-	/* Vsram should not exceed the maximum allowed voltage of SoC. */
-	new_vsram = min(new_vproc + soc_data->min_volt_shift,
-			soc_data->sram_max_volt);
-
-	if (pre_vproc < new_vproc) {
-		/*
-		 * When scaling up voltages, Vsram and Vproc scale up step
-		 * by step. At each step, set Vsram to (Vproc + 200mV) first,
-		 * then set Vproc to (Vsram - 100mV).
-		 * Keep doing it until Vsram and Vproc hit target voltages.
-		 */
-		do {
-			pre_vsram = regulator_get_voltage(sram_reg);
-			if (pre_vsram < 0) {
-				dev_err(info->cpu_dev,
-					"invalid Vsram value: %d\n", pre_vsram);
-				return pre_vsram;
-			}
-			pre_vproc = regulator_get_voltage(proc_reg);
-			if (pre_vproc < 0) {
-				dev_err(info->cpu_dev,
-					"invalid Vproc value: %d\n", pre_vproc);
-				return pre_vproc;
-			}
-
-			vsram = min(new_vsram,
-				    pre_vproc + soc_data->min_volt_shift);
 
-			if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
-				vsram = soc_data->sram_max_volt;
+	pre_vsram = regulator_get_voltage(sram_reg);
+	if (pre_vsram < 0) {
+		dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
+		return pre_vsram;
+	}
 
-				/*
-				 * If the target Vsram hits the maximum voltage,
-				 * try to set the exact voltage value first.
-				 */
-				ret = regulator_set_voltage(sram_reg, vsram,
-							    vsram);
-				if (ret)
-					ret = regulator_set_voltage(sram_reg,
-							vsram - VOLT_TOL,
-							vsram);
+	new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
+			  soc_data->sram_min_volt, soc_data->sram_max_volt);
 
-				vproc = new_vproc;
-			} else {
-				ret = regulator_set_voltage(sram_reg, vsram,
-							    vsram + VOLT_TOL);
+	do {
+		if (pre_vproc <= new_vproc) {
+			vsram = clamp(pre_vproc + soc_data->max_volt_shift,
+				      soc_data->sram_min_volt, new_vsram);
+			ret = regulator_set_voltage(sram_reg, vsram,
+						    soc_data->sram_max_volt);
 
-				vproc = vsram - soc_data->min_volt_shift;
-			}
 			if (ret)
 				return ret;
 
+			if (vsram == soc_data->sram_max_volt ||
+			    new_vsram == soc_data->sram_min_volt)
+				vproc = new_vproc;
+			else
+				vproc = vsram - soc_data->min_volt_shift;
+
 			ret = regulator_set_voltage(proc_reg, vproc,
-						    vproc + VOLT_TOL);
+						    soc_data->proc_max_volt);
 			if (ret) {
 				regulator_set_voltage(sram_reg, pre_vsram,
-						      pre_vsram);
+						      soc_data->sram_max_volt);
 				return ret;
 			}
-		} while (vproc < new_vproc || vsram < new_vsram);
-	} else if (pre_vproc > new_vproc) {
-		/*
-		 * When scaling down voltages, Vsram and Vproc scale down step
-		 * by step. At each step, set Vproc to (Vsram - 200mV) first,
-		 * then set Vproc to (Vproc + 100mV).
-		 * Keep doing it until Vsram and Vproc hit target voltages.
-		 */
-		do {
-			pre_vproc = regulator_get_voltage(proc_reg);
-			if (pre_vproc < 0) {
-				dev_err(info->cpu_dev,
-					"invalid Vproc value: %d\n", pre_vproc);
-				return pre_vproc;
-			}
-			pre_vsram = regulator_get_voltage(sram_reg);
-			if (pre_vsram < 0) {
-				dev_err(info->cpu_dev,
-					"invalid Vsram value: %d\n", pre_vsram);
-				return pre_vsram;
-			}
-
+		} else if (pre_vproc > new_vproc) {
 			vproc = max(new_vproc,
 				    pre_vsram - soc_data->max_volt_shift);
 			ret = regulator_set_voltage(proc_reg, vproc,
-						    vproc + VOLT_TOL);
+						    soc_data->proc_max_volt);
 			if (ret)
 				return ret;
 
@@ -188,32 +140,18 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 				vsram = max(new_vsram,
 					    vproc + soc_data->min_volt_shift);
 
-			if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
-				vsram = soc_data->sram_max_volt;
-
-				/*
-				 * If the target Vsram hits the maximum voltage,
-				 * try to set the exact voltage value first.
-				 */
-				ret = regulator_set_voltage(sram_reg, vsram,
-							    vsram);
-				if (ret)
-					ret = regulator_set_voltage(sram_reg,
-							vsram - VOLT_TOL,
-							vsram);
-			} else {
-				ret = regulator_set_voltage(sram_reg, vsram,
-							    vsram + VOLT_TOL);
-			}
-
+			ret = regulator_set_voltage(sram_reg, vsram,
+						    soc_data->sram_max_volt);
 			if (ret) {
 				regulator_set_voltage(proc_reg, pre_vproc,
-						      pre_vproc);
+						      soc_data->proc_max_volt);
 				return ret;
 			}
-		} while (vproc > new_vproc + VOLT_TOL ||
-			 vsram > new_vsram + VOLT_TOL);
-	}
+		}
+
+		pre_vproc = vproc;
+		pre_vsram = vsram;
+	} while (vproc != new_vproc || vsram != new_vsram);
 
 	return 0;
 }
@@ -275,8 +213,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	 * If the new voltage or the intermediate voltage is higher than the
 	 * current voltage, scale up voltage first.
 	 */
-	target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
-	if (pre_vproc < target_vproc) {
+	target_vproc = max(inter_vproc, vproc);
+	if (pre_vproc <= target_vproc) {
 		ret = mtk_cpufreq_set_voltage(info, target_vproc);
 		if (ret) {
 			dev_err(cpu_dev,
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (7 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 09/15] cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  6:14   ` Hsin-Yi Wang
  2022-04-15  5:59 ` [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
                   ` (5 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

To prevent infinite loop when tracking voltage, we calculate the maximum
value for each platform data.
We assume min voltage is 0 and tracking target voltage using
min_volt_shift for each iteration.
The retry_max is 3 times of expeted iteration count.

Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index cc44a7a9427a..d4c00237e862 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -86,6 +86,16 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 	struct regulator *proc_reg = info->proc_reg;
 	struct regulator *sram_reg = info->sram_reg;
 	int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
+	int retry_max;
+
+	/*
+	 * We assume min voltage is 0 and tracking target voltage using
+	 * min_volt_shift for each iteration.
+	 * The retry_max is 3 times of expeted iteration count.
+	 */
+	retry_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
+					 info->soc_data->proc_max_volt),
+				     info->soc_data->min_volt_shift);
 
 	pre_vproc = regulator_get_voltage(proc_reg);
 	if (pre_vproc < 0) {
@@ -151,6 +161,12 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
 
 		pre_vproc = vproc;
 		pre_vsram = vsram;
+
+		if (--retry_max < 0) {
+			dev_err(info->cpu_dev,
+				"over loop count, failed to set voltage\n");
+			return -EINVAL;
+		}
 	} while (vproc != new_vproc || vsram != new_vsram);
 
 	return 0;
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (8 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-20 18:09   ` Kevin Hilman
  2022-04-15  5:59 ` [PATCH V3 12/15] cpufreq: mediatek: Add support for MT8186 Rex-BC Chen
                   ` (4 subsequent siblings)
  14 siblings, 2 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

In some MediaTek SoCs, like MT8183, CPU and CCI share the same power
supplies. Cpufreq needs to check if CCI devfreq exists and wait until
CCI devfreq ready before scaling frequency.

Before CCI devfreq is ready, we record the voltage when booting to
kernel and use the max(cpu target voltage, booting voltage) to
prevent cpufreq adjust to the lower voltage which will cause the CCI
crash because of high frequency and low voltage.

- Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start
  DVFS when CCI is ready.
- Add platform data for MT8183.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 80 +++++++++++++++++++++++++++++-
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index d4c00237e862..dd3f739fede1 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -22,6 +22,7 @@ struct mtk_cpufreq_platform_data {
 	int proc_max_volt;
 	int sram_min_volt;
 	int sram_max_volt;
+	bool ccifreq_supported;
 };
 
 /*
@@ -38,6 +39,7 @@ struct mtk_cpufreq_platform_data {
 struct mtk_cpu_dvfs_info {
 	struct cpumask cpus;
 	struct device *cpu_dev;
+	struct device *cci_dev;
 	struct regulator *proc_reg;
 	struct regulator *sram_reg;
 	struct clk *cpu_clk;
@@ -45,6 +47,7 @@ struct mtk_cpu_dvfs_info {
 	struct list_head list_head;
 	int intermediate_voltage;
 	bool need_voltage_tracking;
+	int vproc_on_boot;
 	int pre_vproc;
 	/* Avoid race condition for regulators between notify and policy */
 	struct mutex reg_lock;
@@ -52,6 +55,7 @@ struct mtk_cpu_dvfs_info {
 	int opp_cpu;
 	unsigned long opp_freq;
 	const struct mtk_cpufreq_platform_data *soc_data;
+	bool ccifreq_bound;
 };
 
 static struct platform_device *cpufreq_pdev;
@@ -188,6 +192,28 @@ static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc)
 	return ret;
 }
 
+static bool is_ccifreq_ready(struct mtk_cpu_dvfs_info *info)
+{
+	struct device_link *sup_link;
+
+	if (info->ccifreq_bound)
+		return true;
+
+	sup_link = device_link_add(info->cpu_dev, info->cci_dev,
+				   DL_FLAG_AUTOREMOVE_CONSUMER);
+	if (!sup_link) {
+		dev_err(info->cpu_dev, "cpu%d: sup_link is NULL\n", info->opp_cpu);
+		return false;
+	}
+
+	if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+		return false;
+
+	info->ccifreq_bound = true;
+
+	return true;
+}
+
 static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 				  unsigned int index)
 {
@@ -225,6 +251,14 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
 	vproc = dev_pm_opp_get_voltage(opp);
 	dev_pm_opp_put(opp);
 
+	/*
+	 * If MediaTek cci is supported but is not ready, we will use the value
+	 * of max(target cpu voltage, booting voltage) to prevent high freqeuncy
+	 * low voltage crash.
+	 */
+	if (info->soc_data->ccifreq_supported && !is_ccifreq_ready(info))
+		vproc = max(vproc, info->vproc_on_boot);
+
 	/*
 	 * If the new voltage or the intermediate voltage is higher than the
 	 * current voltage, scale up voltage first.
@@ -346,6 +380,23 @@ static int mtk_cpufreq_opp_notifier(struct notifier_block *nb,
 	return notifier_from_errno(ret);
 }
 
+static struct device *of_get_cci(struct device *cpu_dev)
+{
+	struct device_node *np;
+	struct platform_device *pdev;
+
+	np = of_parse_phandle(cpu_dev->of_node, "mediatek,cci", 0);
+	if (IS_ERR_OR_NULL(np))
+		return NULL;
+
+	pdev = of_find_device_by_node(np);
+	of_node_put(np);
+	if (IS_ERR_OR_NULL(pdev))
+		return NULL;
+
+	return &pdev->dev;
+}
+
 static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
 {
 	struct device *cpu_dev;
@@ -360,6 +411,16 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
 	}
 	info->cpu_dev = cpu_dev;
 
+	info->ccifreq_bound = false;
+	if (info->soc_data->ccifreq_supported) {
+		info->cci_dev = of_get_cci(info->cpu_dev);
+		if (IS_ERR_OR_NULL(info->cci_dev)) {
+			ret = PTR_ERR(info->cci_dev);
+			dev_err(cpu_dev, "cpu%d: failed to get cci device\n", cpu);
+			return -ENODEV;
+		}
+	}
+
 	info->cpu_clk = clk_get(cpu_dev, "cpu");
 	if (IS_ERR(info->cpu_clk)) {
 		ret = PTR_ERR(info->cpu_clk);
@@ -423,6 +484,13 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
 	if (ret)
 		goto out_disable_mux_clock;
 
+	info->vproc_on_boot = regulator_get_voltage(info->proc_reg);
+	if (info->vproc_on_boot < 0) {
+		dev_err(info->cpu_dev,
+			"invalid Vproc value: %d\n", info->vproc_on_boot);
+		goto out_disable_inter_clock;
+	}
+
 	/* Search a safe voltage for intermediate frequency. */
 	rate = clk_get_rate(info->inter_clk);
 	opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate);
@@ -623,6 +691,16 @@ static const struct mtk_cpufreq_platform_data mt2701_platform_data = {
 	.proc_max_volt = 1150000,
 	.sram_min_volt = 0,
 	.sram_max_volt = 1150000,
+	.ccifreq_supported = false,
+};
+
+static const struct mtk_cpufreq_platform_data mt8183_platform_data = {
+	.min_volt_shift = 100000,
+	.max_volt_shift = 200000,
+	.proc_max_volt = 1150000,
+	.sram_min_volt = 0,
+	.sram_max_volt = 1150000,
+	.ccifreq_supported = true,
 };
 
 /* List of machines supported by this driver */
@@ -635,7 +713,7 @@ static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
 	{ .compatible = "mediatek,mt817x", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8173", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8176", .data = &mt2701_platform_data },
-	{ .compatible = "mediatek,mt8183", .data = &mt2701_platform_data },
+	{ .compatible = "mediatek,mt8183", .data = &mt8183_platform_data },
 	{ .compatible = "mediatek,mt8365", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8516", .data = &mt2701_platform_data },
 	{ }
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 12/15] cpufreq: mediatek: Add support for MT8186
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (9 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  5:59 ` [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq Rex-BC Chen
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

From: Jia-Wei Chang <jia-wei.chang@mediatek.com>

The platform data of MT8186 is different from previous MediaTek SoCs,
so we add a new compatible and platform data for it.

Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/cpufreq/mediatek-cpufreq.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index dd3f739fede1..dc6cc189414f 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -703,6 +703,15 @@ static const struct mtk_cpufreq_platform_data mt8183_platform_data = {
 	.ccifreq_supported = true,
 };
 
+static const struct mtk_cpufreq_platform_data mt8186_platform_data = {
+	.min_volt_shift = 100000,
+	.max_volt_shift = 250000,
+	.proc_max_volt = 1118750,
+	.sram_min_volt = 850000,
+	.sram_max_volt = 1118750,
+	.ccifreq_supported = true,
+};
+
 /* List of machines supported by this driver */
 static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
 	{ .compatible = "mediatek,mt2701", .data = &mt2701_platform_data },
@@ -714,6 +723,7 @@ static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
 	{ .compatible = "mediatek,mt8173", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8176", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8183", .data = &mt8183_platform_data },
+	{ .compatible = "mediatek,mt8186", .data = &mt8186_platform_data },
 	{ .compatible = "mediatek,mt8365", .data = &mt2701_platform_data },
 	{ .compatible = "mediatek,mt8516", .data = &mt2701_platform_data },
 	{ }
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (10 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 12/15] cpufreq: mediatek: Add support for MT8186 Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
                   ` (2 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen,
	Andrew-sh . Cheng

- Add cpufreq opp table.
- Add MediaTek cci opp table.
- Add property of opp table and clock fro cpufreq.

Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts |  32 +++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi    | 270 ++++++++++++++++++++
 2 files changed, 302 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index f3fd3cca23e9..8953dbf84f3e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -412,6 +412,38 @@
 
 };
 
+&cpu0 {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
+&cpu1 {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
+&cpu2 {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
+&cpu3 {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
+&cpu4 {
+	proc-supply = <&mt6358_vproc11_reg>;
+};
+
+&cpu5 {
+	proc-supply = <&mt6358_vproc11_reg>;
+};
+
+&cpu6 {
+	proc-supply = <&mt6358_vproc11_reg>;
+};
+
+&cpu7 {
+	proc-supply = <&mt6358_vproc11_reg>;
+};
+
 &uart0 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4b08691ed39e..4ae3305d16d2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -42,6 +42,244 @@
 		rdma1 = &rdma1;
 	};
 
+	cluster0_opp: cluster_opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+		opp0_00 {
+			opp-hz = /bits/ 64 <793000000>;
+			opp-microvolt = <650000>;
+			required-opps = <&opp2_00>;
+		};
+		opp0_01 {
+			opp-hz = /bits/ 64 <910000000>;
+			opp-microvolt = <687500>;
+			required-opps = <&opp2_01>;
+		};
+		opp0_02 {
+			opp-hz = /bits/ 64 <1014000000>;
+			opp-microvolt = <718750>;
+			required-opps = <&opp2_02>;
+		};
+		opp0_03 {
+			opp-hz = /bits/ 64 <1131000000>;
+			opp-microvolt = <756250>;
+			required-opps = <&opp2_03>;
+		};
+		opp0_04 {
+			opp-hz = /bits/ 64 <1248000000>;
+			opp-microvolt = <800000>;
+			required-opps = <&opp2_04>;
+		};
+		opp0_05 {
+			opp-hz = /bits/ 64 <1326000000>;
+			opp-microvolt = <818750>;
+			required-opps = <&opp2_05>;
+		};
+		opp0_06 {
+			opp-hz = /bits/ 64 <1417000000>;
+			opp-microvolt = <850000>;
+			required-opps = <&opp2_06>;
+		};
+		opp0_07 {
+			opp-hz = /bits/ 64 <1508000000>;
+			opp-microvolt = <868750>;
+			required-opps = <&opp2_07>;
+		};
+		opp0_08 {
+			opp-hz = /bits/ 64 <1586000000>;
+			opp-microvolt = <893750>;
+			required-opps = <&opp2_08>;
+		};
+		opp0_09 {
+			opp-hz = /bits/ 64 <1625000000>;
+			opp-microvolt = <906250>;
+			required-opps = <&opp2_09>;
+		};
+		opp0_10 {
+			opp-hz = /bits/ 64 <1677000000>;
+			opp-microvolt = <931250>;
+			required-opps = <&opp2_10>;
+		};
+		opp0_11 {
+			opp-hz = /bits/ 64 <1716000000>;
+			opp-microvolt = <943750>;
+			required-opps = <&opp2_11>;
+		};
+		opp0_12 {
+			opp-hz = /bits/ 64 <1781000000>;
+			opp-microvolt = <975000>;
+			required-opps = <&opp2_12>;
+		};
+		opp0_13 {
+			opp-hz = /bits/ 64 <1846000000>;
+			opp-microvolt = <1000000>;
+			required-opps = <&opp2_13>;
+		};
+		opp0_14 {
+			opp-hz = /bits/ 64 <1924000000>;
+			opp-microvolt = <1025000>;
+			required-opps = <&opp2_14>;
+		};
+		opp0_15 {
+			opp-hz = /bits/ 64 <1989000000>;
+			opp-microvolt = <1050000>;
+			required-opps = <&opp2_15>;
+		};	};
+
+	cluster1_opp: cluster_opp_table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+		opp1_00 {
+			opp-hz = /bits/ 64 <793000000>;
+			opp-microvolt = <700000>;
+			required-opps = <&opp2_00>;
+		};
+		opp1_01 {
+			opp-hz = /bits/ 64 <910000000>;
+			opp-microvolt = <725000>;
+			required-opps = <&opp2_01>;
+		};
+		opp1_02 {
+			opp-hz = /bits/ 64 <1014000000>;
+			opp-microvolt = <750000>;
+			required-opps = <&opp2_02>;
+		};
+		opp1_03 {
+			opp-hz = /bits/ 64 <1131000000>;
+			opp-microvolt = <775000>;
+			required-opps = <&opp2_03>;
+		};
+		opp1_04 {
+			opp-hz = /bits/ 64 <1248000000>;
+			opp-microvolt = <800000>;
+			required-opps = <&opp2_04>;
+		};
+		opp1_05 {
+			opp-hz = /bits/ 64 <1326000000>;
+			opp-microvolt = <825000>;
+			required-opps = <&opp2_05>;
+		};
+		opp1_06 {
+			opp-hz = /bits/ 64 <1417000000>;
+			opp-microvolt = <850000>;
+			required-opps = <&opp2_06>;
+		};
+		opp1_07 {
+			opp-hz = /bits/ 64 <1508000000>;
+			opp-microvolt = <875000>;
+			required-opps = <&opp2_07>;
+		};
+		opp1_08 {
+			opp-hz = /bits/ 64 <1586000000>;
+			opp-microvolt = <900000>;
+			required-opps = <&opp2_08>;
+		};
+		opp1_09 {
+			opp-hz = /bits/ 64 <1625000000>;
+			opp-microvolt = <912500>;
+			required-opps = <&opp2_09>;
+		};
+		opp1_10 {
+			opp-hz = /bits/ 64 <1677000000>;
+			opp-microvolt = <931250>;
+			required-opps = <&opp2_10>;
+		};
+		opp1_11 {
+			opp-hz = /bits/ 64 <1716000000>;
+			opp-microvolt = <950000>;
+			required-opps = <&opp2_11>;
+		};
+		opp1_12 {
+			opp-hz = /bits/ 64 <1781000000>;
+			opp-microvolt = <975000>;
+			required-opps = <&opp2_12>;
+		};
+		opp1_13 {
+			opp-hz = /bits/ 64 <1846000000>;
+			opp-microvolt = <1000000>;
+			required-opps = <&opp2_13>;
+		};
+		opp1_14 {
+			opp-hz = /bits/ 64 <1924000000>;
+			opp-microvolt = <1025000>;
+			required-opps = <&opp2_14>;
+		};
+		opp1_15 {
+			opp-hz = /bits/ 64 <1989000000>;
+			opp-microvolt = <1050000>;
+			required-opps = <&opp2_15>;
+		};
+	};
+
+	cci_opp: opp_table2 {
+		compatible = "operating-points-v2";
+		opp-shared;
+		opp2_00: opp-273000000 {
+			opp-hz = /bits/ 64 <273000000>;
+			opp-microvolt = <650000>;
+		};
+		opp2_01: opp-338000000 {
+			opp-hz = /bits/ 64 <338000000>;
+			opp-microvolt = <687500>;
+		};
+		opp2_02: opp-403000000 {
+			opp-hz = /bits/ 64 <403000000>;
+			opp-microvolt = <718750>;
+		};
+		opp2_03: opp-463000000 {
+			opp-hz = /bits/ 64 <463000000>;
+			opp-microvolt = <756250>;
+		};
+		opp2_04: opp-546000000 {
+			opp-hz = /bits/ 64 <546000000>;
+			opp-microvolt = <800000>;
+		};
+		opp2_05: opp-624000000 {
+			opp-hz = /bits/ 64 <624000000>;
+			opp-microvolt = <818750>;
+		};
+		opp2_06: opp-689000000 {
+			opp-hz = /bits/ 64 <689000000>;
+			opp-microvolt = <850000>;
+		};
+		opp2_07: opp-767000000 {
+			opp-hz = /bits/ 64 <767000000>;
+			opp-microvolt = <868750>;
+		};
+		opp2_08: opp-845000000 {
+			opp-hz = /bits/ 64 <845000000>;
+			opp-microvolt = <893750>;
+		};
+		opp2_09: opp-871000000 {
+			opp-hz = /bits/ 64 <871000000>;
+			opp-microvolt = <906250>;
+		};
+		opp2_10: opp-923000000 {
+			opp-hz = /bits/ 64 <923000000>;
+			opp-microvolt = <931250>;
+		};
+		opp2_11: opp-962000000 {
+			opp-hz = /bits/ 64 <962000000>;
+			opp-microvolt = <943750>;
+		};
+		opp2_12: opp-1027000000 {
+			opp-hz = /bits/ 64 <1027000000>;
+			opp-microvolt = <975000>;
+		};
+		opp2_13: opp-1092000000 {
+			opp-hz = /bits/ 64 <1092000000>;
+			opp-microvolt = <1000000>;
+		};
+		opp2_14: opp-1144000000 {
+			opp-hz = /bits/ 64 <1144000000>;
+			opp-microvolt = <1025000>;
+		};
+		opp2_15: opp-1196000000 {
+			opp-hz = /bits/ 64 <1196000000>;
+			opp-microvolt = <1050000>;
+		};
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -85,6 +323,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <741>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP0>;
+			clocks = <&mcucfg CLK_MCU_MP0_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
 		};
@@ -96,6 +338,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <741>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP0>;
+			clocks = <&mcucfg CLK_MCU_MP0_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
 		};
@@ -107,6 +353,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <741>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP0>;
+			clocks = <&mcucfg CLK_MCU_MP0_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
 		};
@@ -118,6 +368,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <741>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP0>;
+			clocks = <&mcucfg CLK_MCU_MP0_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
 		};
@@ -129,6 +383,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <1024>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP1>;
+			clocks = <&mcucfg CLK_MCU_MP2_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
 		};
@@ -140,6 +398,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <1024>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP1>;
+			clocks = <&mcucfg CLK_MCU_MP2_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
 		};
@@ -151,6 +413,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <1024>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP1>;
+			clocks = <&mcucfg CLK_MCU_MP2_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
 		};
@@ -162,6 +428,10 @@
 			enable-method = "psci";
 			capacity-dmips-mhz = <1024>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP1>;
+			clocks = <&mcucfg CLK_MCU_MP2_SEL>,
+				 <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
+			clock-names = "cpu", "intermediate";
+			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
 		};
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (11 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15  6:06   ` Hsin-Yi Wang
  2022-04-15 12:23   ` AngeloGioacchino Del Regno
  2022-04-15  5:59 ` [PATCH V3 15/15] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq Rex-BC Chen
       [not found] ` <20220415055916.28350-6-rex-bc.chen@mediatek.com>
  14 siblings, 2 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen,
	Andrew-sh . Cheng

Add MediaTek CCI devfreq node for MT8183.

Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts    | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi       | 7 +++++++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 8953dbf84f3e..7ac9864db9de 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -412,6 +412,10 @@
 
 };
 
+&cci {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
 &cpu0 {
 	proc-supply = <&mt6358_vproc12_reg>;
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index 0f9480f91261..4786a32ee975 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -230,6 +230,10 @@
 	status = "okay";
 };
 
+&cci {
+	proc-supply = <&mt6358_vproc12_reg>;
+};
+
 &cpu0 {
 	proc-supply = <&mt6358_vproc12_reg>;
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4ae3305d16d2..334728413582 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -280,6 +280,13 @@
 		};
 	};
 
+	cci: cci {
+		compatible = "mediatek,mt8183-cci";
+		clocks = <&apmixedsys CLK_APMIXED_CCIPLL>;
+		clock-names = "cci_clock";
+		operating-points-v2 = <&cci_opp>;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 15/15] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq
  2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
                   ` (12 preceding siblings ...)
  2022-04-15  5:59 ` [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
@ 2022-04-15  5:59 ` Rex-BC Chen
  2022-04-15 12:23   ` AngeloGioacchino Del Regno
       [not found] ` <20220415055916.28350-6-rex-bc.chen@mediatek.com>
  14 siblings, 1 reply; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  5:59 UTC (permalink / raw)
  To: rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman,
	angelogioacchino.delregno, linux-pm, devicetree, linux-kernel,
	linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Rex-BC Chen

Add mediatek,cci property to support MediaTek CCI feature.

Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 334728413582..03b5941796d9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -336,6 +336,7 @@
 			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu1: cpu@1 {
@@ -351,6 +352,7 @@
 			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu2: cpu@2 {
@@ -366,6 +368,7 @@
 			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu3: cpu@3 {
@@ -381,6 +384,7 @@
 			operating-points-v2 = <&cluster0_opp>;
 			dynamic-power-coefficient = <84>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu4: cpu@100 {
@@ -396,6 +400,7 @@
 			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu5: cpu@101 {
@@ -411,6 +416,7 @@
 			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu6: cpu@102 {
@@ -426,6 +432,7 @@
 			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		cpu7: cpu@103 {
@@ -441,6 +448,7 @@
 			operating-points-v2 = <&cluster1_opp>;
 			dynamic-power-coefficient = <211>;
 			#cooling-cells = <2>;
+			mediatek,cci = <&cci>;
 		};
 
 		idle-states {
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183
  2022-04-15  5:59 ` [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
@ 2022-04-15  6:06   ` Hsin-Yi Wang
  2022-04-15  6:10     ` Hsin-Yi Wang
  2022-04-15 12:23   ` AngeloGioacchino Del Regno
  1 sibling, 1 reply; 34+ messages in thread
From: Hsin-Yi Wang @ 2022-04-15  6:06 UTC (permalink / raw)
  To: Rex-BC Chen
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, angelogioacchino.delregno,
	linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, Project_Global_Chrome_Upstream_Group,
	Andrew-sh . Cheng

On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <rex-bc.chen@mediatek.com> wrote:
>
> Add MediaTek CCI devfreq node for MT8183.
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts    | 4 ++++
>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 ++++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi       | 7 +++++++
>  3 files changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index 8953dbf84f3e..7ac9864db9de 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -412,6 +412,10 @@
>
>  };
>
> +&cci {
> +       proc-supply = <&mt6358_vproc12_reg>;
> +};
> +
>  &cpu0 {
>         proc-supply = <&mt6358_vproc12_reg>;
>  };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index 0f9480f91261..4786a32ee975 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -230,6 +230,10 @@
>         status = "okay";
>  };
>
> +&cci {
> +       proc-supply = <&mt6358_vproc12_reg>;
> +};
> +
>  &cpu0 {
>         proc-supply = <&mt6358_vproc12_reg>;
>  };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 4ae3305d16d2..334728413582 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -280,6 +280,13 @@
>                 };
>         };
>
> +       cci: cci {
> +               compatible = "mediatek,mt8183-cci";
> +               clocks = <&apmixedsys CLK_APMIXED_CCIPLL>;
> +               clock-names = "cci_clock";
> +               operating-points-v2 = <&cci_opp>;

hi Rex,

cci_opp is not defined in dts.

> +       };
> +
>         cpus {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
> --
> 2.18.0
>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183
  2022-04-15  6:06   ` Hsin-Yi Wang
@ 2022-04-15  6:10     ` Hsin-Yi Wang
  0 siblings, 0 replies; 34+ messages in thread
From: Hsin-Yi Wang @ 2022-04-15  6:10 UTC (permalink / raw)
  To: Rex-BC Chen
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, angelogioacchino.delregno,
	linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, Project_Global_Chrome_Upstream_Group,
	Andrew-sh . Cheng

On Fri, Apr 15, 2022 at 2:06 PM Hsin-Yi Wang <hsinyi@google.com> wrote:
>
> On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <rex-bc.chen@mediatek.com> wrote:
> >
> > Add MediaTek CCI devfreq node for MT8183.
> >
> > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8183-evb.dts    | 4 ++++
> >  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 ++++
> >  arch/arm64/boot/dts/mediatek/mt8183.dtsi       | 7 +++++++
> >  3 files changed, 15 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > index 8953dbf84f3e..7ac9864db9de 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > @@ -412,6 +412,10 @@
> >
> >  };
> >
> > +&cci {
> > +       proc-supply = <&mt6358_vproc12_reg>;
> > +};
> > +
> >  &cpu0 {
> >         proc-supply = <&mt6358_vproc12_reg>;
> >  };
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > index 0f9480f91261..4786a32ee975 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > @@ -230,6 +230,10 @@
> >         status = "okay";
> >  };
> >
> > +&cci {
> > +       proc-supply = <&mt6358_vproc12_reg>;
> > +};
> > +
> >  &cpu0 {
> >         proc-supply = <&mt6358_vproc12_reg>;
> >  };
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 4ae3305d16d2..334728413582 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -280,6 +280,13 @@
> >                 };
> >         };
> >
> > +       cci: cci {
> > +               compatible = "mediatek,mt8183-cci";
> > +               clocks = <&apmixedsys CLK_APMIXED_CCIPLL>;
> > +               clock-names = "cci_clock";
> > +               operating-points-v2 = <&cci_opp>;
>
> hi Rex,
>
> cci_opp is not defined in dts.
>
It's in the previous patch. Please ignore this comment.

> > +       };
> > +
> >         cpus {
> >                 #address-cells = <1>;
> >                 #size-cells = <0>;
> > --
> > 2.18.0
> >

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  2022-04-15  5:59 ` [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage Rex-BC Chen
@ 2022-04-15  6:14   ` Hsin-Yi Wang
  2022-04-15  6:29     ` Rex-BC Chen
  2022-04-15 12:24     ` AngeloGioacchino Del Regno
  0 siblings, 2 replies; 34+ messages in thread
From: Hsin-Yi Wang @ 2022-04-15  6:14 UTC (permalink / raw)
  To: Rex-BC Chen
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, angelogioacchino.delregno,
	linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, Project_Global_Chrome_Upstream_Group

On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <rex-bc.chen@mediatek.com> wrote:
>
> To prevent infinite loop when tracking voltage, we calculate the maximum
> value for each platform data.
> We assume min voltage is 0 and tracking target voltage using
> min_volt_shift for each iteration.
> The retry_max is 3 times of expeted iteration count.
>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> ---
>  drivers/cpufreq/mediatek-cpufreq.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index cc44a7a9427a..d4c00237e862 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -86,6 +86,16 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
>         struct regulator *proc_reg = info->proc_reg;
>         struct regulator *sram_reg = info->sram_reg;
>         int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> +       int retry_max;
> +
> +       /*
> +        * We assume min voltage is 0 and tracking target voltage using
> +        * min_volt_shift for each iteration.
> +        * The retry_max is 3 times of expeted iteration count.
> +        */
> +       retry_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> +                                        info->soc_data->proc_max_volt),
> +                                    info->soc_data->min_volt_shift);

mtk_cpufreq_voltage_tracking() will be called very frequently.
retry_max is the same every time mtk_cpufreq_voltage_tracking() is
called. Is it better to calculate before and store in
mtk_cpu_dvfs_info?

>
>         pre_vproc = regulator_get_voltage(proc_reg);
>         if (pre_vproc < 0) {
> @@ -151,6 +161,12 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
>
>                 pre_vproc = vproc;
>                 pre_vsram = vsram;
> +
> +               if (--retry_max < 0) {
> +                       dev_err(info->cpu_dev,
> +                               "over loop count, failed to set voltage\n");
> +                       return -EINVAL;
> +               }
>         } while (vproc != new_vproc || vsram != new_vsram);
>
>         return 0;
> --
> 2.18.0
>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  2022-04-15  6:14   ` Hsin-Yi Wang
@ 2022-04-15  6:29     ` Rex-BC Chen
  2022-04-15 12:24     ` AngeloGioacchino Del Regno
  1 sibling, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-15  6:29 UTC (permalink / raw)
  To: Hsin-Yi Wang
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, angelogioacchino.delregno,
	linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, Project_Global_Chrome_Upstream_Group

On Fri, 2022-04-15 at 14:14 +0800, Hsin-Yi Wang wrote:
> On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <rex-bc.chen@mediatek.com
> > wrote:
> > 
> > To prevent infinite loop when tracking voltage, we calculate the
> > maximum
> > value for each platform data.
> > We assume min voltage is 0 and tracking target voltage using
> > min_volt_shift for each iteration.
> > The retry_max is 3 times of expeted iteration count.
> > 
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> >  drivers/cpufreq/mediatek-cpufreq.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> > b/drivers/cpufreq/mediatek-cpufreq.c
> > index cc44a7a9427a..d4c00237e862 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > @@ -86,6 +86,16 @@ static int mtk_cpufreq_voltage_tracking(struct
> > mtk_cpu_dvfs_info *info,
> >         struct regulator *proc_reg = info->proc_reg;
> >         struct regulator *sram_reg = info->sram_reg;
> >         int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> > +       int retry_max;
> > +
> > +       /*
> > +        * We assume min voltage is 0 and tracking target voltage
> > using
> > +        * min_volt_shift for each iteration.
> > +        * The retry_max is 3 times of expeted iteration count.
> > +        */
> > +       retry_max = 3 * DIV_ROUND_UP(max(info->soc_data-
> > >sram_max_volt,
> > +                                        info->soc_data-
> > >proc_max_volt),
> > +                                    info->soc_data-
> > >min_volt_shift);
> 
> mtk_cpufreq_voltage_tracking() will be called very frequently.
> retry_max is the same every time mtk_cpufreq_voltage_tracking() is
> called. Is it better to calculate before and store in
> mtk_cpu_dvfs_info?
> 

Hello Hsin-Yi,

Thanks for your reviwew.
I will do this in next version.

BRs,
Rex

> > 
> >         pre_vproc = regulator_get_voltage(proc_reg);
> >         if (pre_vproc < 0) {
> > @@ -151,6 +161,12 @@ static int mtk_cpufreq_voltage_tracking(struct
> > mtk_cpu_dvfs_info *info,
> > 
> >                 pre_vproc = vproc;
> >                 pre_vsram = vsram;
> > +
> > +               if (--retry_max < 0) {
> > +                       dev_err(info->cpu_dev,
> > +                               "over loop count, failed to set
> > voltage\n");
> > +                       return -EINVAL;
> > +               }
> >         } while (vproc != new_vproc || vsram != new_vsram);
> > 
> >         return 0;
> > --
> > 2.18.0
> > 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 15/15] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq
  2022-04-15  5:59 ` [PATCH V3 15/15] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq Rex-BC Chen
@ 2022-04-15 12:23   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:23 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> Add mediatek,cci property to support MediaTek CCI feature.
> 
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183
  2022-04-15  5:59 ` [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
  2022-04-15  6:06   ` Hsin-Yi Wang
@ 2022-04-15 12:23   ` AngeloGioacchino Del Regno
  1 sibling, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:23 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> Add MediaTek CCI devfreq node for MT8183.
> 
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq
  2022-04-15  5:59 ` [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-18  1:46     ` Rex-BC Chen
  0 siblings, 1 reply; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> - Add cpufreq opp table.
> - Add MediaTek cci opp table.
> - Add property of opp table and clock fro cpufreq.
> 
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> ---
>   arch/arm64/boot/dts/mediatek/mt8183-evb.dts |  32 +++
>   arch/arm64/boot/dts/mediatek/mt8183.dtsi    | 270 ++++++++++++++++++++
>   2 files changed, 302 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index f3fd3cca23e9..8953dbf84f3e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts

..snip..

> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 4b08691ed39e..4ae3305d16d2 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -42,6 +42,244 @@
>   		rdma1 = &rdma1;
>   	};
>   
> +	cluster0_opp: cluster_opp_table0 {

Please don't use underscores in devicetree for anything that's not a phandle.

	cluster0_opp: cluster0-opp-table {

> +		compatible = "operating-points-v2";
> +		opp-shared;
> +		opp0_00 {

Apart from the underscore being invalid, across the kernel, you can find many
instances of opp tables, containing names related to the frequencies, so, for
consistency (this is not a rule!), perhaps it would be a good idea to do so.

		opp-793000000 {

> +			opp-hz = /bits/ 64 <793000000>;
> +			opp-microvolt = <650000>;
> +			required-opps = <&opp2_00>;
> +		};
> +		opp0_01 {

		opp-910000000 {

> +			opp-hz = /bits/ 64 <910000000>;
> +			opp-microvolt = <687500>;
> +			required-opps = <&opp2_01>;
> +		};
> +		opp0_02 {

..snip..

> +		opp0_15 {
> +			opp-hz = /bits/ 64 <1989000000>;
> +			opp-microvolt = <1050000>;
> +			required-opps = <&opp2_15>;

P.S.: Please fix the typo below!

> +		};	};
> +
> +

...also...

> +	cci_opp: opp_table2 {

	cci_opp: cci-opp-table {

> +		compatible = "operating-points-v2";
> +		opp-shared;
> +		opp2_00: opp-273000000 {

This one is fine instead :))

Cheers,
Angelo

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU
  2022-04-15  5:59 ` [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-18  1:45     ` Rex-BC Chen
  2022-04-20 18:09   ` Kevin Hilman
  1 sibling, 1 reply; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> 
> In some MediaTek SoCs, like MT8183, CPU and CCI share the same power
> supplies. Cpufreq needs to check if CCI devfreq exists and wait until
> CCI devfreq ready before scaling frequency.
> 
> Before CCI devfreq is ready, we record the voltage when booting to
> kernel and use the max(cpu target voltage, booting voltage) to
> prevent cpufreq adjust to the lower voltage which will cause the CCI
> crash because of high frequency and low voltage.
> 
> - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start
>    DVFS when CCI is ready.
> - Add platform data for MT8183.
> 
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

I am enthusiast to see that the solution that I've proposed was welcome!

I only have one nit on this patch, check below:

> ---
>   drivers/cpufreq/mediatek-cpufreq.c | 80 +++++++++++++++++++++++++++++-
>   1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index d4c00237e862..dd3f739fede1 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c

..snip..

> @@ -225,6 +251,14 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
>   	vproc = dev_pm_opp_get_voltage(opp);
>   	dev_pm_opp_put(opp);
>   
> +	/*
> +	 * If MediaTek cci is supported but is not ready, we will use the value
> +	 * of max(target cpu voltage, booting voltage) to prevent high freqeuncy
> +	 * low voltage crash.
> +	 */
> +	if (info->soc_data->ccifreq_supported && !is_ccifreq_ready(info))
> +		vproc = max(vproc, info->vproc_on_boot);
> +
>   	/*
>   	 * If the new voltage or the intermediate voltage is higher than the
>   	 * current voltage, scale up voltage first.

..snip..

> @@ -423,6 +484,13 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>   	if (ret)
>   		goto out_disable_mux_clock;
>   
> +	info->vproc_on_boot = regulator_get_voltage(info->proc_reg);

This result is used only if we use ccifreq, so this should be enclosed in an if
condition: this will spare us some (yes, small) time on devices that don't use it.

	if (info->soc_data->ccifreq_supported) {
		info->vproc_on_boot = regulator_get_voltage(info->proc_reg);
		if (info->vproc_on_boot < 0) {
			dev_err(....
			goto ..
		}
	}

P.S.: While at it, since the maximum width is 100 columns, the dev_err() call fits,
so don't break that line!

After the requested change:

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  2022-04-15  6:14   ` Hsin-Yi Wang
  2022-04-15  6:29     ` Rex-BC Chen
@ 2022-04-15 12:24     ` AngeloGioacchino Del Regno
  2022-04-18  1:40       ` Rex-BC Chen
  1 sibling, 1 reply; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Hsin-Yi Wang, Rex-BC Chen
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 08:14, Hsin-Yi Wang ha scritto:
> On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <rex-bc.chen@mediatek.com> wrote:
>>
>> To prevent infinite loop when tracking voltage, we calculate the maximum
>> value for each platform data.
>> We assume min voltage is 0 and tracking target voltage using
>> min_volt_shift for each iteration.
>> The retry_max is 3 times of expeted iteration count.
>>
>> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

I'm sorry Rex, but this commit has to be squashed with 09/15, as the logic is
that each commit has to be acceptable, and 09/15 is not, without this fix.

Besides, as Hsin-Yi suggested, calculating this every time may hit performance,
but at the same time I don't want to lose this explicit calculation...

>> ---
>>   drivers/cpufreq/mediatek-cpufreq.c | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
>> index cc44a7a9427a..d4c00237e862 100644
>> --- a/drivers/cpufreq/mediatek-cpufreq.c
>> +++ b/drivers/cpufreq/mediatek-cpufreq.c
>> @@ -86,6 +86,16 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
>>          struct regulator *proc_reg = info->proc_reg;
>>          struct regulator *sram_reg = info->sram_reg;
>>          int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
>> +       int retry_max;
>> +
>> +       /*
>> +        * We assume min voltage is 0 and tracking target voltage using
>> +        * min_volt_shift for each iteration.
>> +        * The retry_max is 3 times of expeted iteration count.
>> +        */
>> +       retry_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
>> +                                        info->soc_data->proc_max_volt),
>> +                                    info->soc_data->min_volt_shift);
> 
> mtk_cpufreq_voltage_tracking() will be called very frequently.
> retry_max is the same every time mtk_cpufreq_voltage_tracking() is
> called. Is it better to calculate before and store in
> mtk_cpu_dvfs_info?
> 

...so I agree with this solution: perhaps you can add a "vtrack_max" variable to
mtk_cpu_dvfs_info as suggested, and fill in that one in function
mtk_cpu_dvfs_info_init(), where we effectively initialize all-the-things.

Cheers,
Angelo

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data
  2022-04-15  5:59 ` [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> 
> Voltages and shifts are defined as macros originally.
> There are different requirements of these values for each MediaTek SoCs.
> Therefore, we add the platform data and move these values into it.
> 
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>


Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 05/15] cpufreq: mediatek: Add opp notification support
       [not found] ` <20220415055916.28350-6-rex-bc.chen@mediatek.com>
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh.Cheng

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
> 
>  From this opp notifier, cpufreq should listen to opp notification and do
> proper actions when receiving events of disable and voltage adjustment.
> 
> One of the user for this opp notifier is MediaTek SVS.
> The MediaTek Smart Voltage Scaling (SVS) is a hardware which calculates
> suitable SVS bank voltages to OPP voltage table.
> 
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> ---
>   drivers/cpufreq/mediatek-cpufreq.c | 93 +++++++++++++++++++++++++++---
>   1 file changed, 85 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index fa8b193bf27b..221f249f8d21 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -41,6 +41,11 @@ struct mtk_cpu_dvfs_info {
>   	int intermediate_voltage;
>   	bool need_voltage_tracking;
>   	int pre_vproc;
> +	/* Avoid race condition for regulators between notify and policy */
> +	struct mutex reg_lock;
> +	struct notifier_block opp_nb;
> +	int opp_cpu;

This should be unsigned int because:
1. A negative CPU number is impossible;
2. The only usage is as a parameter of cpufreq_cpu_get(unsigned int cpu).

Please change this to unsigned int, after which:

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value
  2022-04-15  5:59 ` [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  2022-04-18  1:37     ` Rex-BC Chen
  0 siblings, 1 reply; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> 
> We found the buck voltage may not be exactly the same with what we set
> because CPU may share the same buck with other module.
> Therefore, we need to record the previous desired value instead of reading
> it from regulators.
> 
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> ---
>   drivers/cpufreq/mediatek-cpufreq.c | 17 +++++++++++++----
>   1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index ff27f77e8ee6..fa8b193bf27b 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -40,6 +40,7 @@ struct mtk_cpu_dvfs_info {
>   	struct list_head list_head;
>   	int intermediate_voltage;
>   	bool need_voltage_tracking;
> +	int pre_vproc;
>   };
>   
>   static LIST_HEAD(dvfs_info_list);
> @@ -191,11 +192,17 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
>   
>   static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc)
>   {
> +	int ret;
> +
>   	if (info->need_voltage_tracking)
> -		return mtk_cpufreq_voltage_tracking(info, vproc);
> +		ret = mtk_cpufreq_voltage_tracking(info, vproc);
>   	else
> -		return regulator_set_voltage(info->proc_reg, vproc,
> -					     vproc + VOLT_TOL);
> +		ret = regulator_set_voltage(info->proc_reg, vproc,
> +					    MAX_VOLT_LIMIT);
> +	if (!ret)
> +		info->pre_vproc = vproc;
> +
> +	return ret;
>   }
>   
>   static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> @@ -213,7 +220,9 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
>   	inter_vproc = info->intermediate_voltage;
>   
>   	pre_freq_hz = clk_get_rate(cpu_clk);
> -	pre_vproc = regulator_get_voltage(info->proc_reg);
> +	pre_vproc = info->pre_vproc;
> +	if (pre_vproc <= 0)
> +		pre_vproc = regulator_get_voltage(info->proc_reg);

I would do it like that, instead:

	if (unlikely(info->pre_vproc <= 0))
		pre_vproc = regulator_get_voltage(info->proc_reg);
	else
		pre_vproc = info->pre_vproc;

....as even though it is indeed possible that info->pre_vproc is <= 0, it is
very unlikely to happen ;-)
This also solves a 'pre_vproc' double assignment issue, by the way.

Cheers,
Angelo




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_*
  2022-04-15  5:59 ` [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_* Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> To make driver more readable, replace old_* with pre_*.
> 
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs
  2022-04-15  5:59 ` [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs Rex-BC Chen
@ 2022-04-15 12:24   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 34+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-04-15 12:24 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> - Replace pr_* with dev_* to show logs.
> - Remove usage of __func__.
> 
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
@ 2022-04-18  1:37     ` Rex-BC Chen
  0 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-18  1:37 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, rafael, viresh.kumar, robh+dt,
	krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng

On Fri, 2022-04-15 at 14:24 +0200, AngeloGioacchino Del Regno wrote:
> Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> > From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> > 
> > We found the buck voltage may not be exactly the same with what we
> > set
> > because CPU may share the same buck with other module.
> > Therefore, we need to record the previous desired value instead of
> > reading
> > it from regulators.
> > 
> > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> >   drivers/cpufreq/mediatek-cpufreq.c | 17 +++++++++++++----
> >   1 file changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> > b/drivers/cpufreq/mediatek-cpufreq.c
> > index ff27f77e8ee6..fa8b193bf27b 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > @@ -40,6 +40,7 @@ struct mtk_cpu_dvfs_info {
> >   	struct list_head list_head;
> >   	int intermediate_voltage;
> >   	bool need_voltage_tracking;
> > +	int pre_vproc;
> >   };
> >   
> >   static LIST_HEAD(dvfs_info_list);
> > @@ -191,11 +192,17 @@ static int
> > mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> >   
> >   static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info
> > *info, int vproc)
> >   {
> > +	int ret;
> > +
> >   	if (info->need_voltage_tracking)
> > -		return mtk_cpufreq_voltage_tracking(info, vproc);
> > +		ret = mtk_cpufreq_voltage_tracking(info, vproc);
> >   	else
> > -		return regulator_set_voltage(info->proc_reg, vproc,
> > -					     vproc + VOLT_TOL);
> > +		ret = regulator_set_voltage(info->proc_reg, vproc,
> > +					    MAX_VOLT_LIMIT);
> > +	if (!ret)
> > +		info->pre_vproc = vproc;
> > +
> > +	return ret;
> >   }
> >   
> >   static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> > @@ -213,7 +220,9 @@ static int mtk_cpufreq_set_target(struct
> > cpufreq_policy *policy,
> >   	inter_vproc = info->intermediate_voltage;
> >   
> >   	pre_freq_hz = clk_get_rate(cpu_clk);
> > -	pre_vproc = regulator_get_voltage(info->proc_reg);
> > +	pre_vproc = info->pre_vproc;
> > +	if (pre_vproc <= 0)
> > +		pre_vproc = regulator_get_voltage(info->proc_reg);
> 
> I would do it like that, instead:
> 
> 	if (unlikely(info->pre_vproc <= 0))
> 		pre_vproc = regulator_get_voltage(info->proc_reg);
> 	else
> 		pre_vproc = info->pre_vproc;
> 
> ....as even though it is indeed possible that info->pre_vproc is <=
> 0, it is
> very unlikely to happen ;-)
> This also solves a 'pre_vproc' double assignment issue, by the way.
> 
> Cheers,
> Angelo
> 
> 
> 

Hello Angelo,

OK, I will add this in next version.
Thanks for your suggestion.

BRs,
Rex


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage
  2022-04-15 12:24     ` AngeloGioacchino Del Regno
@ 2022-04-18  1:40       ` Rex-BC Chen
  0 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-18  1:40 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, Hsin-Yi Wang
  Cc: rafael, Viresh Kumar, Rob Herring, krzk+dt, Matthias Brugger,
	Tim Chang, roger.lu, Kevin Hilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

On Fri, 2022-04-15 at 14:24 +0200, AngeloGioacchino Del Regno wrote:
> Il 15/04/22 08:14, Hsin-Yi Wang ha scritto:
> > On Fri, Apr 15, 2022 at 1:59 PM Rex-BC Chen <
> > rex-bc.chen@mediatek.com> wrote:
> > > 
> > > To prevent infinite loop when tracking voltage, we calculate the
> > > maximum
> > > value for each platform data.
> > > We assume min voltage is 0 and tracking target voltage using
> > > min_volt_shift for each iteration.
> > > The retry_max is 3 times of expeted iteration count.
> > > 
> > > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> 
> I'm sorry Rex, but this commit has to be squashed with 09/15, as the
> logic is
> that each commit has to be acceptable, and 09/15 is not, without this
> fix.
> 
> Besides, as Hsin-Yi suggested, calculating this every time may hit
> performance,
> but at the same time I don't want to lose this explicit
> calculation...
> 

Hello Angelo,

I will squash thius patch into 9/15 and will use info->vtrack_max to
record the value in probe function.

Thanks!

BRs,
Rex

> > > ---
> > >   drivers/cpufreq/mediatek-cpufreq.c | 16 ++++++++++++++++
> > >   1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> > > b/drivers/cpufreq/mediatek-cpufreq.c
> > > index cc44a7a9427a..d4c00237e862 100644
> > > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > > @@ -86,6 +86,16 @@ static int mtk_cpufreq_voltage_tracking(struct
> > > mtk_cpu_dvfs_info *info,
> > >          struct regulator *proc_reg = info->proc_reg;
> > >          struct regulator *sram_reg = info->sram_reg;
> > >          int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> > > +       int retry_max;
> > > +
> > > +       /*
> > > +        * We assume min voltage is 0 and tracking target voltage
> > > using
> > > +        * min_volt_shift for each iteration.
> > > +        * The retry_max is 3 times of expeted iteration count.
> > > +        */
> > > +       retry_max = 3 * DIV_ROUND_UP(max(info->soc_data-
> > > >sram_max_volt,
> > > +                                        info->soc_data-
> > > >proc_max_volt),
> > > +                                    info->soc_data-
> > > >min_volt_shift);
> > 
> > mtk_cpufreq_voltage_tracking() will be called very frequently.
> > retry_max is the same every time mtk_cpufreq_voltage_tracking() is
> > called. Is it better to calculate before and store in
> > mtk_cpu_dvfs_info?
> > 
> 
> ...so I agree with this solution: perhaps you can add a "vtrack_max"
> variable to
> mtk_cpu_dvfs_info as suggested, and fill in that one in function
> mtk_cpu_dvfs_info_init(), where we effectively initialize all-the-
> things.
> 
> Cheers,
> Angelo


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
@ 2022-04-18  1:45     ` Rex-BC Chen
  0 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-18  1:45 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, rafael, viresh.kumar, robh+dt,
	krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group

On Fri, 2022-04-15 at 14:24 +0200, AngeloGioacchino Del Regno wrote:
> Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> > From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> > 
> > In some MediaTek SoCs, like MT8183, CPU and CCI share the same
> > power
> > supplies. Cpufreq needs to check if CCI devfreq exists and wait
> > until
> > CCI devfreq ready before scaling frequency.
> > 
> > Before CCI devfreq is ready, we record the voltage when booting to
> > kernel and use the max(cpu target voltage, booting voltage) to
> > prevent cpufreq adjust to the lower voltage which will cause the
> > CCI
> > crash because of high frequency and low voltage.
> > 
> > - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will
> > start
> >    DVFS when CCI is ready.
> > - Add platform data for MT8183.
> > 
> > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> 
> I am enthusiast to see that the solution that I've proposed was
> welcome!
> 
> I only have one nit on this patch, check below:
> 

Hello Angelo,

Thanks for your advice for this modification.
I also reply to Kevin and describe this solution.
Let's wait for Kevin's feedback and other suggestion.

> > ---
> >   drivers/cpufreq/mediatek-cpufreq.c | 80
> > +++++++++++++++++++++++++++++-
> >   1 file changed, 79 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> > b/drivers/cpufreq/mediatek-cpufreq.c
> > index d4c00237e862..dd3f739fede1 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> 
> ..snip..
> 
> > @@ -225,6 +251,14 @@ static int mtk_cpufreq_set_target(struct
> > cpufreq_policy *policy,
> >   	vproc = dev_pm_opp_get_voltage(opp);
> >   	dev_pm_opp_put(opp);
> >   
> > +	/*
> > +	 * If MediaTek cci is supported but is not ready, we will use
> > the value
> > +	 * of max(target cpu voltage, booting voltage) to prevent high
> > freqeuncy
> > +	 * low voltage crash.
> > +	 */
> > +	if (info->soc_data->ccifreq_supported &&
> > !is_ccifreq_ready(info))
> > +		vproc = max(vproc, info->vproc_on_boot);
> > +
> >   	/*
> >   	 * If the new voltage or the intermediate voltage is higher
> > than the
> >   	 * current voltage, scale up voltage first.
> 
> ..snip..
> 
> > @@ -423,6 +484,13 @@ static int mtk_cpu_dvfs_info_init(struct
> > mtk_cpu_dvfs_info *info, int cpu)
> >   	if (ret)
> >   		goto out_disable_mux_clock;
> >   
> > +	info->vproc_on_boot = regulator_get_voltage(info->proc_reg);
> 
> This result is used only if we use ccifreq, so this should be
> enclosed in an if
> condition: this will spare us some (yes, small) time on devices that
> don't use it.
> 
> 	if (info->soc_data->ccifreq_supported) {
> 		info->vproc_on_boot = regulator_get_voltage(info-
> >proc_reg);
> 		if (info->vproc_on_boot < 0) {
> 			dev_err(....
> 			goto ..
> 		}
> 	}
> 
> P.S.: While at it, since the maximum width is 100 columns, the
> dev_err() call fits,
> so don't break that line!
> 
> After the requested change:
> 
> Reviewed-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>

I will add this in next version if there is no any suggestion for this
patch.

Thanks!

BRs,
Rex


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
@ 2022-04-18  1:46     ` Rex-BC Chen
  0 siblings, 0 replies; 34+ messages in thread
From: Rex-BC Chen @ 2022-04-18  1:46 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, rafael, viresh.kumar, robh+dt,
	krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, khilman, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek,
	Project_Global_Chrome_Upstream_Group, Andrew-sh . Cheng

On Fri, 2022-04-15 at 14:24 +0200, AngeloGioacchino Del Regno wrote:
> Il 15/04/22 07:59, Rex-BC Chen ha scritto:
> > - Add cpufreq opp table.
> > - Add MediaTek cci opp table.
> > - Add property of opp table and clock fro cpufreq.
> > 
> > Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> >   arch/arm64/boot/dts/mediatek/mt8183-evb.dts |  32 +++
> >   arch/arm64/boot/dts/mediatek/mt8183.dtsi    | 270
> > ++++++++++++++++++++
> >   2 files changed, 302 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > index f3fd3cca23e9..8953dbf84f3e 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> 
> ..snip..
> 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 4b08691ed39e..4ae3305d16d2 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -42,6 +42,244 @@
> >   		rdma1 = &rdma1;
> >   	};
> >   
> > +	cluster0_opp: cluster_opp_table0 {
> 
> Please don't use underscores in devicetree for anything that's not a
> phandle.
> 
> 	cluster0_opp: cluster0-opp-table {
> 
> > +		compatible = "operating-points-v2";
> > +		opp-shared;
> > +		opp0_00 {
> 
> Apart from the underscore being invalid, across the kernel, you can
> find many
> instances of opp tables, containing names related to the frequencies,
> so, for
> consistency (this is not a rule!), perhaps it would be a good idea to
> do so.
> 
> 		opp-793000000 {
> 
> > +			opp-hz = /bits/ 64 <793000000>;
> > +			opp-microvolt = <650000>;
> > +			required-opps = <&opp2_00>;
> > +		};
> > +		opp0_01 {
> 
> 		opp-910000000 {
> 
> > +			opp-hz = /bits/ 64 <910000000>;
> > +			opp-microvolt = <687500>;
> > +			required-opps = <&opp2_01>;
> > +		};
> > +		opp0_02 {
> 
> ..snip..
> 
> > +		opp0_15 {
> > +			opp-hz = /bits/ 64 <1989000000>;
> > +			opp-microvolt = <1050000>;
> > +			required-opps = <&opp2_15>;
> 
> P.S.: Please fix the typo below!
> 
> > +		};	};
> > +
> > +
> 
> ...also...
> 
> > +	cci_opp: opp_table2 {
> 
> 	cci_opp: cci-opp-table {
> 
> > +		compatible = "operating-points-v2";
> > +		opp-shared;
> > +		opp2_00: opp-273000000 {
> 
> This one is fine instead :))
> 
> Cheers,
> Angelo

Hello Angelo,

OK, I will modify this issue in next version.
Thanks!

BRs,
Rex


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU
  2022-04-15  5:59 ` [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
  2022-04-15 12:24   ` AngeloGioacchino Del Regno
@ 2022-04-20 18:09   ` Kevin Hilman
  1 sibling, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2022-04-20 18:09 UTC (permalink / raw)
  To: Rex-BC Chen, rafael, viresh.kumar, robh+dt, krzk+dt, matthias.bgg
  Cc: jia-wei.chang, roger.lu, hsinyi, angelogioacchino.delregno,
	linux-pm, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, Project_Global_Chrome_Upstream_Group,
	Rex-BC Chen

Hi Rex,

Rex-BC Chen <rex-bc.chen@mediatek.com> writes:

> From: Jia-Wei Chang <jia-wei.chang@mediatek.com>
>
> In some MediaTek SoCs, like MT8183, CPU and CCI share the same power
> supplies. Cpufreq needs to check if CCI devfreq exists and wait until
> CCI devfreq ready before scaling frequency.
>
> Before CCI devfreq is ready, we record the voltage when booting to
> kernel and use the max(cpu target voltage, booting voltage) to
> prevent cpufreq adjust to the lower voltage which will cause the CCI
> crash because of high frequency and low voltage.
>
> - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start
>   DVFS when CCI is ready.
> - Add platform data for MT8183.
>
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>

The solution of keeping the max of the CPU voltage from OPP and boot-up
voltage makes sense until CCI is ready.  Thank you for the rework and
the detailed technical explanations.

Reviewed-by: Kevin Hilman <khilman@baylibre.com>

Kevin

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2022-04-20 18:10 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-15  5:59 [PATCH V3 00/15] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 01/15] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 02/15] cpufreq: mediatek: Use device print to show logs Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-15  5:59 ` [PATCH V3 03/15] cpufreq: mediatek: Replace old_* with pre_* Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-15  5:59 ` [PATCH V3 04/15] cpufreq: mediatek: Record previous target vproc value Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-18  1:37     ` Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 06/15] cpufreq: mediatek: Move voltage limits to platform data Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-15  5:59 ` [PATCH V3 07/15] cpufreq: mediatek: Add .get function Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 08/15] cpufreq: mediatek: Make sram regulator optional Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 09/15] cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 10/15] cpufreq: mediatek: Add counter to prevent infinite loop when tracking voltage Rex-BC Chen
2022-04-15  6:14   ` Hsin-Yi Wang
2022-04-15  6:29     ` Rex-BC Chen
2022-04-15 12:24     ` AngeloGioacchino Del Regno
2022-04-18  1:40       ` Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 11/15] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-18  1:45     ` Rex-BC Chen
2022-04-20 18:09   ` Kevin Hilman
2022-04-15  5:59 ` [PATCH V3 12/15] cpufreq: mediatek: Add support for MT8186 Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 13/15] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq Rex-BC Chen
2022-04-15 12:24   ` AngeloGioacchino Del Regno
2022-04-18  1:46     ` Rex-BC Chen
2022-04-15  5:59 ` [PATCH V3 14/15] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
2022-04-15  6:06   ` Hsin-Yi Wang
2022-04-15  6:10     ` Hsin-Yi Wang
2022-04-15 12:23   ` AngeloGioacchino Del Regno
2022-04-15  5:59 ` [PATCH V3 15/15] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq Rex-BC Chen
2022-04-15 12:23   ` AngeloGioacchino Del Regno
     [not found] ` <20220415055916.28350-6-rex-bc.chen@mediatek.com>
2022-04-15 12:24   ` [PATCH V3 05/15] cpufreq: mediatek: Add opp notification support AngeloGioacchino Del Regno

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).