All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1 0/13] Enahance SVS's robustness
@ 2022-12-26  9:42 ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS driver got accepted upstream but still has room to be improved.
Therefore, we add these patches to fix issues and coding style.

Matthias Brugger (4):
  soc: mediatek: mtk-svs: clean up platform probing
  soc: mediatek: mtk-svs: improve readability of platform_probe
  soc: mediatek: mtk-svs: move svs_platform_probe into probe
  soc: mediatek: mtk-svs: delete superfluous platform data entries

Ricardo Ribalda (1):
  soc: mediatek: mtk-svs: enable the IRQ later

Roger Lu (7):
  soc: mediatek: mtk-svs: use svs get efuse common function
  soc: mtk-svs: mt8183: refactor o_slope calculation
  soc: mediatek: mtk-svs: add main_clk check during system-wide suspend
  soc: mediatek: mtk-svs: use common function to disable restore
    voltages
  soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
  soc: mediatek: mtk-svs: add thermal voltage compensation if needed
  soc: mediatek: mtk-svs: keep svs alive even though debug cmd create
    fail

Shang XiaoJing (1):
  soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in
    svs_init01()

 drivers/soc/mediatek/mtk-svs.c | 279 +++++++++++++++------------------
 1 file changed, 124 insertions(+), 155 deletions(-)



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

* [PATCH v1 0/13] Enahance SVS's robustness
@ 2022-12-26  9:42 ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS driver got accepted upstream but still has room to be improved.
Therefore, we add these patches to fix issues and coding style.

Matthias Brugger (4):
  soc: mediatek: mtk-svs: clean up platform probing
  soc: mediatek: mtk-svs: improve readability of platform_probe
  soc: mediatek: mtk-svs: move svs_platform_probe into probe
  soc: mediatek: mtk-svs: delete superfluous platform data entries

Ricardo Ribalda (1):
  soc: mediatek: mtk-svs: enable the IRQ later

Roger Lu (7):
  soc: mediatek: mtk-svs: use svs get efuse common function
  soc: mtk-svs: mt8183: refactor o_slope calculation
  soc: mediatek: mtk-svs: add main_clk check during system-wide suspend
  soc: mediatek: mtk-svs: use common function to disable restore
    voltages
  soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
  soc: mediatek: mtk-svs: add thermal voltage compensation if needed
  soc: mediatek: mtk-svs: keep svs alive even though debug cmd create
    fail

Shang XiaoJing (1):
  soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in
    svs_init01()

 drivers/soc/mediatek/mtk-svs.c | 279 +++++++++++++++------------------
 1 file changed, 124 insertions(+), 155 deletions(-)



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 01/13] soc: mediatek: mtk-svs: enable the IRQ later
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Ricardo Ribalda

From: Ricardo Ribalda <ribalda@chromium.org>

If the system does not come from reset (like when is booted via
kexec(), the peripheral might trigger an IRQ before the data structures
are initialized.

Fixes:

[    0.227710] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000f08
[    0.227913] Call trace:
[    0.227918]  svs_isr+0x8c/0x538

Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 0469c9dfeb04..91e06f43969d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2379,20 +2379,6 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_free_resource;
 	}
 
-	svsp_irq = platform_get_irq(pdev, 0);
-	if (svsp_irq < 0) {
-		ret = svsp_irq;
-		goto svs_probe_free_resource;
-	}
-
-	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
-					IRQF_ONESHOT, svsp->name, svsp);
-	if (ret) {
-		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
-			svsp_irq, ret);
-		goto svs_probe_free_resource;
-	}
-
 	svsp->main_clk = devm_clk_get(svsp->dev, "main");
 	if (IS_ERR(svsp->main_clk)) {
 		dev_err(svsp->dev, "failed to get clock: %ld\n",
@@ -2414,6 +2400,20 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_clk_disable;
 	}
 
+	svsp_irq = platform_get_irq(pdev, 0);
+	if (svsp_irq < 0) {
+		ret = svsp_irq;
+		goto svs_probe_iounmap;
+	}
+
+	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+					IRQF_ONESHOT, svsp->name, svsp);
+	if (ret) {
+		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+			svsp_irq, ret);
+		goto svs_probe_iounmap;
+	}
+
 	ret = svs_start(svsp);
 	if (ret) {
 		dev_err(svsp->dev, "svs start fail: %d\n", ret);
-- 
2.18.0


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

* [PATCH v1 01/13] soc: mediatek: mtk-svs: enable the IRQ later
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Ricardo Ribalda

From: Ricardo Ribalda <ribalda@chromium.org>

If the system does not come from reset (like when is booted via
kexec(), the peripheral might trigger an IRQ before the data structures
are initialized.

Fixes:

[    0.227710] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000f08
[    0.227913] Call trace:
[    0.227918]  svs_isr+0x8c/0x538

Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 0469c9dfeb04..91e06f43969d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2379,20 +2379,6 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_free_resource;
 	}
 
-	svsp_irq = platform_get_irq(pdev, 0);
-	if (svsp_irq < 0) {
-		ret = svsp_irq;
-		goto svs_probe_free_resource;
-	}
-
-	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
-					IRQF_ONESHOT, svsp->name, svsp);
-	if (ret) {
-		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
-			svsp_irq, ret);
-		goto svs_probe_free_resource;
-	}
-
 	svsp->main_clk = devm_clk_get(svsp->dev, "main");
 	if (IS_ERR(svsp->main_clk)) {
 		dev_err(svsp->dev, "failed to get clock: %ld\n",
@@ -2414,6 +2400,20 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_clk_disable;
 	}
 
+	svsp_irq = platform_get_irq(pdev, 0);
+	if (svsp_irq < 0) {
+		ret = svsp_irq;
+		goto svs_probe_iounmap;
+	}
+
+	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+					IRQF_ONESHOT, svsp->name, svsp);
+	if (ret) {
+		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+			svsp_irq, ret);
+		goto svs_probe_iounmap;
+	}
+
 	ret = svs_start(svsp);
 	if (ret) {
 		dev_err(svsp->dev, "svs start fail: %d\n", ret);
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 02/13] soc: mediatek: mtk-svs: clean up platform probing
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

We only ever call the SoC specific probe function from
svs_platform_probe. No need to carry that function in a global
datastructure around.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 91e06f43969d..38dcee9c9c04 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -319,7 +319,6 @@ static const u32 svs_regs_v2[] = {
  * @banks: svs banks that svs platform supports
  * @rst: svs platform reset control
  * @efuse_parsing: svs platform efuse parsing function pointer
- * @probe: svs platform probe function pointer
  * @efuse_max: total number of svs efuse
  * @tefuse_max: total number of thermal efuse
  * @regs: svs platform registers map
@@ -336,7 +335,6 @@ struct svs_platform {
 	struct svs_bank *banks;
 	struct reset_control *rst;
 	bool (*efuse_parsing)(struct svs_platform *svsp);
-	int (*probe)(struct svs_platform *svsp);
 	size_t efuse_max;
 	size_t tefuse_max;
 	const u32 *regs;
@@ -2347,11 +2345,10 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 	svsp->name = svsp_data->name;
 	svsp->banks = svsp_data->banks;
 	svsp->efuse_parsing = svsp_data->efuse_parsing;
-	svsp->probe = svsp_data->probe;
 	svsp->regs = svsp_data->regs;
 	svsp->bank_max = svsp_data->bank_max;
 
-	ret = svsp->probe(svsp);
+	ret = svsp_data->probe(svsp);
 	if (ret)
 		return ERR_PTR(ret);
 
-- 
2.18.0


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

* [PATCH v1 02/13] soc: mediatek: mtk-svs: clean up platform probing
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

We only ever call the SoC specific probe function from
svs_platform_probe. No need to carry that function in a global
datastructure around.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 91e06f43969d..38dcee9c9c04 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -319,7 +319,6 @@ static const u32 svs_regs_v2[] = {
  * @banks: svs banks that svs platform supports
  * @rst: svs platform reset control
  * @efuse_parsing: svs platform efuse parsing function pointer
- * @probe: svs platform probe function pointer
  * @efuse_max: total number of svs efuse
  * @tefuse_max: total number of thermal efuse
  * @regs: svs platform registers map
@@ -336,7 +335,6 @@ struct svs_platform {
 	struct svs_bank *banks;
 	struct reset_control *rst;
 	bool (*efuse_parsing)(struct svs_platform *svsp);
-	int (*probe)(struct svs_platform *svsp);
 	size_t efuse_max;
 	size_t tefuse_max;
 	const u32 *regs;
@@ -2347,11 +2345,10 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 	svsp->name = svsp_data->name;
 	svsp->banks = svsp_data->banks;
 	svsp->efuse_parsing = svsp_data->efuse_parsing;
-	svsp->probe = svsp_data->probe;
 	svsp->regs = svsp_data->regs;
 	svsp->bank_max = svsp_data->bank_max;
 
-	ret = svsp->probe(svsp);
+	ret = svsp_data->probe(svsp);
 	if (ret)
 		return ERR_PTR(ret);
 
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 03/13] soc: mediatek: mtk-svs: improve readability of platform_probe
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

If a compatible misses a match data entry, then something is wrong in
the development phase, we don't need to check for that at runtime.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 38dcee9c9c04..63ad9160a305 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2332,10 +2332,6 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 	int ret;
 
 	svsp_data = of_device_get_match_data(&pdev->dev);
-	if (!svsp_data) {
-		dev_err(&pdev->dev, "no svs platform data?\n");
-		return ERR_PTR(-EPERM);
-	}
 
 	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
 	if (!svsp)
-- 
2.18.0


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

* [PATCH v1 03/13] soc: mediatek: mtk-svs: improve readability of platform_probe
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

If a compatible misses a match data entry, then something is wrong in
the development phase, we don't need to check for that at runtime.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 38dcee9c9c04..63ad9160a305 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2332,10 +2332,6 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 	int ret;
 
 	svsp_data = of_device_get_match_data(&pdev->dev);
-	if (!svsp_data) {
-		dev_err(&pdev->dev, "no svs platform data?\n");
-		return ERR_PTR(-EPERM);
-	}
 
 	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
 	if (!svsp)
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 04/13] soc: mediatek: mtk-svs: move svs_platform_probe into probe
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

Moving svs_platform_probe into driver probe function will allow us to
reduce svs_platform members. This will be done in a follow-up patch.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 63ad9160a305..24d2d07d2d3d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2325,17 +2325,17 @@ static const struct of_device_id svs_of_match[] = {
 	},
 };
 
-static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
+static int svs_probe(struct platform_device *pdev)
 {
 	struct svs_platform *svsp;
 	const struct svs_platform_data *svsp_data;
-	int ret;
+	int ret, svsp_irq;
 
 	svsp_data = of_device_get_match_data(&pdev->dev);
 
 	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
 	if (!svsp)
-		return ERR_PTR(-ENOMEM);
+		return -ENOMEM;
 
 	svsp->dev = &pdev->dev;
 	svsp->name = svsp_data->name;
@@ -2346,19 +2346,7 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 
 	ret = svsp_data->probe(svsp);
 	if (ret)
-		return ERR_PTR(ret);
-
-	return svsp;
-}
-
-static int svs_probe(struct platform_device *pdev)
-{
-	struct svs_platform *svsp;
-	int svsp_irq, ret;
-
-	svsp = svs_platform_probe(pdev);
-	if (IS_ERR(svsp))
-		return PTR_ERR(svsp);
+		return ret;
 
 	if (!svs_is_efuse_data_correct(svsp)) {
 		dev_notice(svsp->dev, "efuse data isn't correct\n");
-- 
2.18.0


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

* [PATCH v1 04/13] soc: mediatek: mtk-svs: move svs_platform_probe into probe
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

Moving svs_platform_probe into driver probe function will allow us to
reduce svs_platform members. This will be done in a follow-up patch.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 63ad9160a305..24d2d07d2d3d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2325,17 +2325,17 @@ static const struct of_device_id svs_of_match[] = {
 	},
 };
 
-static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
+static int svs_probe(struct platform_device *pdev)
 {
 	struct svs_platform *svsp;
 	const struct svs_platform_data *svsp_data;
-	int ret;
+	int ret, svsp_irq;
 
 	svsp_data = of_device_get_match_data(&pdev->dev);
 
 	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
 	if (!svsp)
-		return ERR_PTR(-ENOMEM);
+		return -ENOMEM;
 
 	svsp->dev = &pdev->dev;
 	svsp->name = svsp_data->name;
@@ -2346,19 +2346,7 @@ static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
 
 	ret = svsp_data->probe(svsp);
 	if (ret)
-		return ERR_PTR(ret);
-
-	return svsp;
-}
-
-static int svs_probe(struct platform_device *pdev)
-{
-	struct svs_platform *svsp;
-	int svsp_irq, ret;
-
-	svsp = svs_platform_probe(pdev);
-	if (IS_ERR(svsp))
-		return PTR_ERR(svsp);
+		return ret;
 
 	if (!svs_is_efuse_data_correct(svsp)) {
 		dev_notice(svsp->dev, "efuse data isn't correct\n");
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 05/13] soc: mediatek: mtk-svs: delete superfluous platform data entries
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

The platform name and efuse parsing function pointer are only used while
probing the device. Use them from the svs_platform_data struct instead.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 24d2d07d2d3d..5c9ca373e646 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -311,14 +311,12 @@ static const u32 svs_regs_v2[] = {
 
 /**
  * struct svs_platform - svs platform control
- * @name: svs platform name
  * @base: svs platform register base
  * @dev: svs platform device
  * @main_clk: main clock for svs bank
  * @pbank: svs bank pointer needing to be protected by spin_lock section
  * @banks: svs banks that svs platform supports
  * @rst: svs platform reset control
- * @efuse_parsing: svs platform efuse parsing function pointer
  * @efuse_max: total number of svs efuse
  * @tefuse_max: total number of thermal efuse
  * @regs: svs platform registers map
@@ -327,14 +325,12 @@ static const u32 svs_regs_v2[] = {
  * @tefuse: thermal efuse data received from NVMEM framework
  */
 struct svs_platform {
-	char *name;
 	void __iomem *base;
 	struct device *dev;
 	struct clk *main_clk;
 	struct svs_bank *pbank;
 	struct svs_bank *banks;
 	struct reset_control *rst;
-	bool (*efuse_parsing)(struct svs_platform *svsp);
 	size_t efuse_max;
 	size_t tefuse_max;
 	const u32 *regs;
@@ -2009,7 +2005,7 @@ static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
 	svsp->efuse_max /= sizeof(u32);
 	nvmem_cell_put(cell);
 
-	return svsp->efuse_parsing(svsp);
+	return true;
 }
 
 static struct device *svs_get_subsys_device(struct svs_platform *svsp,
@@ -2338,9 +2334,7 @@ static int svs_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	svsp->dev = &pdev->dev;
-	svsp->name = svsp_data->name;
 	svsp->banks = svsp_data->banks;
-	svsp->efuse_parsing = svsp_data->efuse_parsing;
 	svsp->regs = svsp_data->regs;
 	svsp->bank_max = svsp_data->bank_max;
 
@@ -2351,6 +2345,12 @@ static int svs_probe(struct platform_device *pdev)
 	if (!svs_is_efuse_data_correct(svsp)) {
 		dev_notice(svsp->dev, "efuse data isn't correct\n");
 		ret = -EPERM;
+		goto svs_probe_free_efuse;
+	}
+
+	if (!svsp_data->efuse_parsing(svsp)) {
+		dev_err(svsp->dev, "efuse data parsing failed\n");
+		ret = -EPERM;
 		goto svs_probe_free_resource;
 	}
 
@@ -2388,7 +2388,7 @@ static int svs_probe(struct platform_device *pdev)
 	}
 
 	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
-					IRQF_ONESHOT, svsp->name, svsp);
+					IRQF_ONESHOT, svsp_data->name, svsp);
 	if (ret) {
 		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
 			svsp_irq, ret);
@@ -2416,11 +2416,13 @@ static int svs_probe(struct platform_device *pdev)
 	clk_disable_unprepare(svsp->main_clk);
 
 svs_probe_free_resource:
-	if (!IS_ERR_OR_NULL(svsp->efuse))
-		kfree(svsp->efuse);
 	if (!IS_ERR_OR_NULL(svsp->tefuse))
 		kfree(svsp->tefuse);
 
+svs_probe_free_efuse:
+	if (!IS_ERR_OR_NULL(svsp->efuse))
+		kfree(svsp->efuse);
+
 	return ret;
 }
 
-- 
2.18.0


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

* [PATCH v1 05/13] soc: mediatek: mtk-svs: delete superfluous platform data entries
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

From: Matthias Brugger <matthias.bgg@gmail.com>

The platform name and efuse parsing function pointer are only used while
probing the device. Use them from the svs_platform_data struct instead.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 24d2d07d2d3d..5c9ca373e646 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -311,14 +311,12 @@ static const u32 svs_regs_v2[] = {
 
 /**
  * struct svs_platform - svs platform control
- * @name: svs platform name
  * @base: svs platform register base
  * @dev: svs platform device
  * @main_clk: main clock for svs bank
  * @pbank: svs bank pointer needing to be protected by spin_lock section
  * @banks: svs banks that svs platform supports
  * @rst: svs platform reset control
- * @efuse_parsing: svs platform efuse parsing function pointer
  * @efuse_max: total number of svs efuse
  * @tefuse_max: total number of thermal efuse
  * @regs: svs platform registers map
@@ -327,14 +325,12 @@ static const u32 svs_regs_v2[] = {
  * @tefuse: thermal efuse data received from NVMEM framework
  */
 struct svs_platform {
-	char *name;
 	void __iomem *base;
 	struct device *dev;
 	struct clk *main_clk;
 	struct svs_bank *pbank;
 	struct svs_bank *banks;
 	struct reset_control *rst;
-	bool (*efuse_parsing)(struct svs_platform *svsp);
 	size_t efuse_max;
 	size_t tefuse_max;
 	const u32 *regs;
@@ -2009,7 +2005,7 @@ static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
 	svsp->efuse_max /= sizeof(u32);
 	nvmem_cell_put(cell);
 
-	return svsp->efuse_parsing(svsp);
+	return true;
 }
 
 static struct device *svs_get_subsys_device(struct svs_platform *svsp,
@@ -2338,9 +2334,7 @@ static int svs_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	svsp->dev = &pdev->dev;
-	svsp->name = svsp_data->name;
 	svsp->banks = svsp_data->banks;
-	svsp->efuse_parsing = svsp_data->efuse_parsing;
 	svsp->regs = svsp_data->regs;
 	svsp->bank_max = svsp_data->bank_max;
 
@@ -2351,6 +2345,12 @@ static int svs_probe(struct platform_device *pdev)
 	if (!svs_is_efuse_data_correct(svsp)) {
 		dev_notice(svsp->dev, "efuse data isn't correct\n");
 		ret = -EPERM;
+		goto svs_probe_free_efuse;
+	}
+
+	if (!svsp_data->efuse_parsing(svsp)) {
+		dev_err(svsp->dev, "efuse data parsing failed\n");
+		ret = -EPERM;
 		goto svs_probe_free_resource;
 	}
 
@@ -2388,7 +2388,7 @@ static int svs_probe(struct platform_device *pdev)
 	}
 
 	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
-					IRQF_ONESHOT, svsp->name, svsp);
+					IRQF_ONESHOT, svsp_data->name, svsp);
 	if (ret) {
 		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
 			svsp_irq, ret);
@@ -2416,11 +2416,13 @@ static int svs_probe(struct platform_device *pdev)
 	clk_disable_unprepare(svsp->main_clk);
 
 svs_probe_free_resource:
-	if (!IS_ERR_OR_NULL(svsp->efuse))
-		kfree(svsp->efuse);
 	if (!IS_ERR_OR_NULL(svsp->tefuse))
 		kfree(svsp->tefuse);
 
+svs_probe_free_efuse:
+	if (!IS_ERR_OR_NULL(svsp->efuse))
+		kfree(svsp->efuse);
+
 	return ret;
 }
 
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 06/13] soc: mediatek: mtk-svs: use svs get efuse common function
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS might need to read both svs efuse and thermal efuse on the probe flow.
Therefore, add a common efuse read function to remove the superfluous
codes.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 69 ++++++++++++----------------------
 1 file changed, 24 insertions(+), 45 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 5c9ca373e646..477f5bd1e1d1 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1701,26 +1701,28 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
 	return 0;
 }
 
-static int svs_thermal_efuse_get_data(struct svs_platform *svsp)
+static int svs_get_efuse_data(struct svs_platform *svsp,
+			      const char *nvmem_cell_name,
+			      u32 **svsp_efuse, size_t *svsp_efuse_max)
 {
 	struct nvmem_cell *cell;
 
-	/* Thermal efuse parsing */
-	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	cell = nvmem_cell_get(svsp->dev, nvmem_cell_name);
 	if (IS_ERR_OR_NULL(cell)) {
-		dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n", PTR_ERR(cell));
+		dev_err(svsp->dev, "no \"%s\"? %ld\n",
+			nvmem_cell_name, PTR_ERR(cell));
 		return PTR_ERR(cell);
 	}
 
-	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
-	if (IS_ERR(svsp->tefuse)) {
-		dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
-			PTR_ERR(svsp->tefuse));
+	*svsp_efuse = nvmem_cell_read(cell, svsp_efuse_max);
+	if (IS_ERR(*svsp_efuse)) {
+		dev_err(svsp->dev, "cannot read \"%s\" efuse: %ld\n",
+			nvmem_cell_name, PTR_ERR(*svsp_efuse));
 		nvmem_cell_put(cell);
-		return PTR_ERR(svsp->tefuse);
+		return PTR_ERR(*svsp_efuse);
 	}
 
-	svsp->tefuse_max /= sizeof(u32);
+	*svsp_efuse_max /= sizeof(u32);
 	nvmem_cell_put(cell);
 
 	return 0;
@@ -1768,7 +1770,8 @@ static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
 		svsb->vmax += svsb->dvt_fixed;
 	}
 
-	ret = svs_thermal_efuse_get_data(svsp);
+	ret = svs_get_efuse_data(svsp, "t-calibration-data",
+				 &svsp->tefuse, &svsp->tefuse_max);
 	if (ret)
 		return false;
 
@@ -1873,7 +1876,8 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		}
 	}
 
-	ret = svs_thermal_efuse_get_data(svsp);
+	ret = svs_get_efuse_data(svsp, "t-calibration-data",
+				 &svsp->tefuse, &svsp->tefuse_max);
 	if (ret)
 		return false;
 
@@ -1982,32 +1986,6 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 	return true;
 }
 
-static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
-{
-	struct nvmem_cell *cell;
-
-	/* Get svs efuse by nvmem */
-	cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
-	if (IS_ERR(cell)) {
-		dev_err(svsp->dev, "no \"svs-calibration-data\"? %ld\n",
-			PTR_ERR(cell));
-		return false;
-	}
-
-	svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_max);
-	if (IS_ERR(svsp->efuse)) {
-		dev_err(svsp->dev, "cannot read svs efuse: %ld\n",
-			PTR_ERR(svsp->efuse));
-		nvmem_cell_put(cell);
-		return false;
-	}
-
-	svsp->efuse_max /= sizeof(u32);
-	nvmem_cell_put(cell);
-
-	return true;
-}
-
 static struct device *svs_get_subsys_device(struct svs_platform *svsp,
 					    const char *node_name)
 {
@@ -2342,8 +2320,9 @@ static int svs_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	if (!svs_is_efuse_data_correct(svsp)) {
-		dev_notice(svsp->dev, "efuse data isn't correct\n");
+	ret = svs_get_efuse_data(svsp, "svs-calibration-data",
+				 &svsp->efuse, &svsp->efuse_max);
+	if (ret) {
 		ret = -EPERM;
 		goto svs_probe_free_efuse;
 	}
@@ -2351,13 +2330,13 @@ static int svs_probe(struct platform_device *pdev)
 	if (!svsp_data->efuse_parsing(svsp)) {
 		dev_err(svsp->dev, "efuse data parsing failed\n");
 		ret = -EPERM;
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	ret = svs_bank_resource_setup(svsp);
 	if (ret) {
 		dev_err(svsp->dev, "svs bank resource setup fail: %d\n", ret);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	svsp->main_clk = devm_clk_get(svsp->dev, "main");
@@ -2365,13 +2344,13 @@ static int svs_probe(struct platform_device *pdev)
 		dev_err(svsp->dev, "failed to get clock: %ld\n",
 			PTR_ERR(svsp->main_clk));
 		ret = PTR_ERR(svsp->main_clk);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	ret = clk_prepare_enable(svsp->main_clk);
 	if (ret) {
 		dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	svsp->base = of_iomap(svsp->dev->of_node, 0);
@@ -2415,7 +2394,7 @@ static int svs_probe(struct platform_device *pdev)
 svs_probe_clk_disable:
 	clk_disable_unprepare(svsp->main_clk);
 
-svs_probe_free_resource:
+svs_probe_free_tefuse:
 	if (!IS_ERR_OR_NULL(svsp->tefuse))
 		kfree(svsp->tefuse);
 
-- 
2.18.0


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

* [PATCH v1 06/13] soc: mediatek: mtk-svs: use svs get efuse common function
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS might need to read both svs efuse and thermal efuse on the probe flow.
Therefore, add a common efuse read function to remove the superfluous
codes.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 69 ++++++++++++----------------------
 1 file changed, 24 insertions(+), 45 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 5c9ca373e646..477f5bd1e1d1 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1701,26 +1701,28 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
 	return 0;
 }
 
-static int svs_thermal_efuse_get_data(struct svs_platform *svsp)
+static int svs_get_efuse_data(struct svs_platform *svsp,
+			      const char *nvmem_cell_name,
+			      u32 **svsp_efuse, size_t *svsp_efuse_max)
 {
 	struct nvmem_cell *cell;
 
-	/* Thermal efuse parsing */
-	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	cell = nvmem_cell_get(svsp->dev, nvmem_cell_name);
 	if (IS_ERR_OR_NULL(cell)) {
-		dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n", PTR_ERR(cell));
+		dev_err(svsp->dev, "no \"%s\"? %ld\n",
+			nvmem_cell_name, PTR_ERR(cell));
 		return PTR_ERR(cell);
 	}
 
-	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
-	if (IS_ERR(svsp->tefuse)) {
-		dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
-			PTR_ERR(svsp->tefuse));
+	*svsp_efuse = nvmem_cell_read(cell, svsp_efuse_max);
+	if (IS_ERR(*svsp_efuse)) {
+		dev_err(svsp->dev, "cannot read \"%s\" efuse: %ld\n",
+			nvmem_cell_name, PTR_ERR(*svsp_efuse));
 		nvmem_cell_put(cell);
-		return PTR_ERR(svsp->tefuse);
+		return PTR_ERR(*svsp_efuse);
 	}
 
-	svsp->tefuse_max /= sizeof(u32);
+	*svsp_efuse_max /= sizeof(u32);
 	nvmem_cell_put(cell);
 
 	return 0;
@@ -1768,7 +1770,8 @@ static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
 		svsb->vmax += svsb->dvt_fixed;
 	}
 
-	ret = svs_thermal_efuse_get_data(svsp);
+	ret = svs_get_efuse_data(svsp, "t-calibration-data",
+				 &svsp->tefuse, &svsp->tefuse_max);
 	if (ret)
 		return false;
 
@@ -1873,7 +1876,8 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		}
 	}
 
-	ret = svs_thermal_efuse_get_data(svsp);
+	ret = svs_get_efuse_data(svsp, "t-calibration-data",
+				 &svsp->tefuse, &svsp->tefuse_max);
 	if (ret)
 		return false;
 
@@ -1982,32 +1986,6 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 	return true;
 }
 
-static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
-{
-	struct nvmem_cell *cell;
-
-	/* Get svs efuse by nvmem */
-	cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
-	if (IS_ERR(cell)) {
-		dev_err(svsp->dev, "no \"svs-calibration-data\"? %ld\n",
-			PTR_ERR(cell));
-		return false;
-	}
-
-	svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_max);
-	if (IS_ERR(svsp->efuse)) {
-		dev_err(svsp->dev, "cannot read svs efuse: %ld\n",
-			PTR_ERR(svsp->efuse));
-		nvmem_cell_put(cell);
-		return false;
-	}
-
-	svsp->efuse_max /= sizeof(u32);
-	nvmem_cell_put(cell);
-
-	return true;
-}
-
 static struct device *svs_get_subsys_device(struct svs_platform *svsp,
 					    const char *node_name)
 {
@@ -2342,8 +2320,9 @@ static int svs_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	if (!svs_is_efuse_data_correct(svsp)) {
-		dev_notice(svsp->dev, "efuse data isn't correct\n");
+	ret = svs_get_efuse_data(svsp, "svs-calibration-data",
+				 &svsp->efuse, &svsp->efuse_max);
+	if (ret) {
 		ret = -EPERM;
 		goto svs_probe_free_efuse;
 	}
@@ -2351,13 +2330,13 @@ static int svs_probe(struct platform_device *pdev)
 	if (!svsp_data->efuse_parsing(svsp)) {
 		dev_err(svsp->dev, "efuse data parsing failed\n");
 		ret = -EPERM;
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	ret = svs_bank_resource_setup(svsp);
 	if (ret) {
 		dev_err(svsp->dev, "svs bank resource setup fail: %d\n", ret);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	svsp->main_clk = devm_clk_get(svsp->dev, "main");
@@ -2365,13 +2344,13 @@ static int svs_probe(struct platform_device *pdev)
 		dev_err(svsp->dev, "failed to get clock: %ld\n",
 			PTR_ERR(svsp->main_clk));
 		ret = PTR_ERR(svsp->main_clk);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	ret = clk_prepare_enable(svsp->main_clk);
 	if (ret) {
 		dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
-		goto svs_probe_free_resource;
+		goto svs_probe_free_tefuse;
 	}
 
 	svsp->base = of_iomap(svsp->dev->of_node, 0);
@@ -2415,7 +2394,7 @@ static int svs_probe(struct platform_device *pdev)
 svs_probe_clk_disable:
 	clk_disable_unprepare(svsp->main_clk);
 
-svs_probe_free_resource:
+svs_probe_free_tefuse:
 	if (!IS_ERR_OR_NULL(svsp->tefuse))
 		kfree(svsp->tefuse);
 
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 07/13] soc: mtk-svs: mt8183: refactor o_slope calculation
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

The o_slope value is dependent of the o_slope_sign, refactor code to get
rid of unnecessary if constructs.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 51 +++++++++++++++-------------------
 1 file changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 477f5bd1e1d1..2c1fbf11b554 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1897,26 +1897,27 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 	o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
 
 	ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
-	o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
-
-	if (adc_cali_en_t == 1) {
-		if (!ts_id)
-			o_slope = 0;
-
-		if (adc_ge_t < 265 || adc_ge_t > 758 ||
-		    adc_oe_t < 265 || adc_oe_t > 758 ||
-		    o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
-		    o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
-		    o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
-		    o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
-		    o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
-		    o_vtsabb < -8 || o_vtsabb > 484 ||
-		    degc_cali < 1 || degc_cali > 63) {
-			dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
-			goto remove_mt8183_svsb_mon_mode;
-		}
+	if (!ts_id) {
+		o_slope = 1534;
 	} else {
-		dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+		o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+		if (!o_slope_sign)
+			o_slope = 1534 + o_slope * 10;
+		else
+			o_slope = 1534 - o_slope * 10;
+	}
+
+	if (adc_cali_en_t == 0 ||
+	    adc_ge_t < 265 || adc_ge_t > 758 ||
+	    adc_oe_t < 265 || adc_oe_t > 758 ||
+	    o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
+	    o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
+	    o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
+	    o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
+	    o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
+	    o_vtsabb < -8 || o_vtsabb > 484 ||
+	    degc_cali < 1 || degc_cali > 63) {
+		dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
 		goto remove_mt8183_svsb_mon_mode;
 	}
 
@@ -1935,11 +1936,7 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / gain;
 
 	temp0 = (10000 * 100000 / gain) * 15 / 18;
-
-	if (!o_slope_sign)
-		mts = (temp0 * 10) / (1534 + o_slope * 10);
-	else
-		mts = (temp0 * 10) / (1534 - o_slope * 10);
+	mts = (temp0 * 10) / o_slope;
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
@@ -1966,11 +1963,7 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		temp0 = (degc_cali * 10 / 2);
 		temp1 = ((10000 * 100000 / 4096 / gain) *
 			 oe + tb_roomt * 10) * 15 / 18;
-
-		if (!o_slope_sign)
-			temp2 = temp1 * 100 / (1534 + o_slope * 10);
-		else
-			temp2 = temp1 * 100 / (1534 - o_slope * 10);
+		temp2 = temp1 * 100 / o_slope;
 
 		svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
 	}
-- 
2.18.0


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

* [PATCH v1 07/13] soc: mtk-svs: mt8183: refactor o_slope calculation
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

The o_slope value is dependent of the o_slope_sign, refactor code to get
rid of unnecessary if constructs.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 51 +++++++++++++++-------------------
 1 file changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 477f5bd1e1d1..2c1fbf11b554 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1897,26 +1897,27 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 	o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
 
 	ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
-	o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
-
-	if (adc_cali_en_t == 1) {
-		if (!ts_id)
-			o_slope = 0;
-
-		if (adc_ge_t < 265 || adc_ge_t > 758 ||
-		    adc_oe_t < 265 || adc_oe_t > 758 ||
-		    o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
-		    o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
-		    o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
-		    o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
-		    o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
-		    o_vtsabb < -8 || o_vtsabb > 484 ||
-		    degc_cali < 1 || degc_cali > 63) {
-			dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
-			goto remove_mt8183_svsb_mon_mode;
-		}
+	if (!ts_id) {
+		o_slope = 1534;
 	} else {
-		dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+		o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+		if (!o_slope_sign)
+			o_slope = 1534 + o_slope * 10;
+		else
+			o_slope = 1534 - o_slope * 10;
+	}
+
+	if (adc_cali_en_t == 0 ||
+	    adc_ge_t < 265 || adc_ge_t > 758 ||
+	    adc_oe_t < 265 || adc_oe_t > 758 ||
+	    o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
+	    o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
+	    o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
+	    o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
+	    o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
+	    o_vtsabb < -8 || o_vtsabb > 484 ||
+	    degc_cali < 1 || degc_cali > 63) {
+		dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
 		goto remove_mt8183_svsb_mon_mode;
 	}
 
@@ -1935,11 +1936,7 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / gain;
 
 	temp0 = (10000 * 100000 / gain) * 15 / 18;
-
-	if (!o_slope_sign)
-		mts = (temp0 * 10) / (1534 + o_slope * 10);
-	else
-		mts = (temp0 * 10) / (1534 - o_slope * 10);
+	mts = (temp0 * 10) / o_slope;
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
@@ -1966,11 +1963,7 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 		temp0 = (degc_cali * 10 / 2);
 		temp1 = ((10000 * 100000 / 4096 / gain) *
 			 oe + tb_roomt * 10) * 15 / 18;
-
-		if (!o_slope_sign)
-			temp2 = temp1 * 100 / (1534 + o_slope * 10);
-		else
-			temp2 = temp1 * 100 / (1534 - o_slope * 10);
+		temp2 = temp1 * 100 / o_slope;
 
 		svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
 	}
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 08/13] soc: mediatek: mtk-svs: add main_clk check during system-wide suspend
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS's main_clk might be disabled in svs_resume(). Therefore, if main_clk
is disabled and svs_suspend() is called by system-wide suspend stage,
return 0 directly.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 2c1fbf11b554..934e7ea976b0 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -6,6 +6,7 @@
 #include <linux/bitfield.h>
 #include <linux/bits.h>
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
 #include <linux/completion.h>
 #include <linux/cpuidle.h>
 #include <linux/debugfs.h>
@@ -1543,6 +1544,9 @@ static int svs_suspend(struct device *dev)
 	int ret;
 	u32 idx;
 
+	if (!__clk_is_enabled(svsp->main_clk))
+		return 0;
+
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
 
-- 
2.18.0


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

* [PATCH v1 08/13] soc: mediatek: mtk-svs: add main_clk check during system-wide suspend
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

SVS's main_clk might be disabled in svs_resume(). Therefore, if main_clk
is disabled and svs_suspend() is called by system-wide suspend stage,
return 0 directly.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 2c1fbf11b554..934e7ea976b0 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -6,6 +6,7 @@
 #include <linux/bitfield.h>
 #include <linux/bits.h>
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
 #include <linux/completion.h>
 #include <linux/cpuidle.h>
 #include <linux/debugfs.h>
@@ -1543,6 +1544,9 @@ static int svs_suspend(struct device *dev)
 	int ret;
 	u32 idx;
 
+	if (!__clk_is_enabled(svsp->main_clk))
+		return 0;
+
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
 
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 09/13] soc: mediatek: mtk-svs: use common function to disable restore voltages
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

The timing of disabling/restoring SVS bank is more than one place.
Therefore, add a common function to use for removing the superfluous codes.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 44 +++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 934e7ea976b0..c4b36c908eda 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -623,6 +623,26 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 	return ret;
 }
 
+static void svs_bank_disable_and_restore_default_volts(struct svs_platform *svsp,
+						       struct svs_bank *svsb)
+{
+	unsigned long flags;
+
+	if (svsb->mode_support == SVSB_MODE_ALL_DISABLE)
+		return;
+
+	/* This spinlock might wait for svs_isr() process */
+	spin_lock_irqsave(&svs_lock, flags);
+	svsp->pbank = svsb;
+	svs_switch_bank(svsp);
+	svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
+	svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
+	spin_unlock_irqrestore(&svs_lock, flags);
+
+	svsb->phase = SVSB_PHASE_ERROR;
+	svs_adjust_pm_opp_volts(svsb);
+}
+
 static int svs_dump_debug_show(struct seq_file *m, void *p)
 {
 	struct svs_platform *svsp = (struct svs_platform *)m->private;
@@ -698,7 +718,6 @@ static ssize_t svs_enable_debug_write(struct file *filp,
 {
 	struct svs_bank *svsb = file_inode(filp)->i_private;
 	struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
-	unsigned long flags;
 	int enabled, ret;
 	char *buf = NULL;
 
@@ -714,16 +733,8 @@ static ssize_t svs_enable_debug_write(struct file *filp,
 		return ret;
 
 	if (!enabled) {
-		spin_lock_irqsave(&svs_lock, flags);
-		svsp->pbank = svsb;
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
 		svsb->mode_support = SVSB_MODE_ALL_DISABLE;
-		svs_switch_bank(svsp);
-		svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
-		svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
-		spin_unlock_irqrestore(&svs_lock, flags);
-
-		svsb->phase = SVSB_PHASE_ERROR;
-		svs_adjust_pm_opp_volts(svsb);
 	}
 
 	kfree(buf);
@@ -1540,7 +1551,6 @@ static int svs_suspend(struct device *dev)
 {
 	struct svs_platform *svsp = dev_get_drvdata(dev);
 	struct svs_bank *svsb;
-	unsigned long flags;
 	int ret;
 	u32 idx;
 
@@ -1549,17 +1559,7 @@ static int svs_suspend(struct device *dev)
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
-
-		/* This might wait for svs_isr() process */
-		spin_lock_irqsave(&svs_lock, flags);
-		svsp->pbank = svsb;
-		svs_switch_bank(svsp);
-		svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
-		svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
-		spin_unlock_irqrestore(&svs_lock, flags);
-
-		svsb->phase = SVSB_PHASE_ERROR;
-		svs_adjust_pm_opp_volts(svsb);
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
 	}
 
 	ret = reset_control_assert(svsp->rst);
-- 
2.18.0


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

* [PATCH v1 09/13] soc: mediatek: mtk-svs: use common function to disable restore voltages
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

The timing of disabling/restoring SVS bank is more than one place.
Therefore, add a common function to use for removing the superfluous codes.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 44 +++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 934e7ea976b0..c4b36c908eda 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -623,6 +623,26 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 	return ret;
 }
 
+static void svs_bank_disable_and_restore_default_volts(struct svs_platform *svsp,
+						       struct svs_bank *svsb)
+{
+	unsigned long flags;
+
+	if (svsb->mode_support == SVSB_MODE_ALL_DISABLE)
+		return;
+
+	/* This spinlock might wait for svs_isr() process */
+	spin_lock_irqsave(&svs_lock, flags);
+	svsp->pbank = svsb;
+	svs_switch_bank(svsp);
+	svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
+	svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
+	spin_unlock_irqrestore(&svs_lock, flags);
+
+	svsb->phase = SVSB_PHASE_ERROR;
+	svs_adjust_pm_opp_volts(svsb);
+}
+
 static int svs_dump_debug_show(struct seq_file *m, void *p)
 {
 	struct svs_platform *svsp = (struct svs_platform *)m->private;
@@ -698,7 +718,6 @@ static ssize_t svs_enable_debug_write(struct file *filp,
 {
 	struct svs_bank *svsb = file_inode(filp)->i_private;
 	struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
-	unsigned long flags;
 	int enabled, ret;
 	char *buf = NULL;
 
@@ -714,16 +733,8 @@ static ssize_t svs_enable_debug_write(struct file *filp,
 		return ret;
 
 	if (!enabled) {
-		spin_lock_irqsave(&svs_lock, flags);
-		svsp->pbank = svsb;
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
 		svsb->mode_support = SVSB_MODE_ALL_DISABLE;
-		svs_switch_bank(svsp);
-		svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
-		svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
-		spin_unlock_irqrestore(&svs_lock, flags);
-
-		svsb->phase = SVSB_PHASE_ERROR;
-		svs_adjust_pm_opp_volts(svsb);
 	}
 
 	kfree(buf);
@@ -1540,7 +1551,6 @@ static int svs_suspend(struct device *dev)
 {
 	struct svs_platform *svsp = dev_get_drvdata(dev);
 	struct svs_bank *svsb;
-	unsigned long flags;
 	int ret;
 	u32 idx;
 
@@ -1549,17 +1559,7 @@ static int svs_suspend(struct device *dev)
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
 		svsb = &svsp->banks[idx];
-
-		/* This might wait for svs_isr() process */
-		spin_lock_irqsave(&svs_lock, flags);
-		svsp->pbank = svsb;
-		svs_switch_bank(svsp);
-		svs_writel_relaxed(svsp, SVSB_PTPEN_OFF, SVSEN);
-		svs_writel_relaxed(svsp, SVSB_INTSTS_VAL_CLEAN, INTSTS);
-		spin_unlock_irqrestore(&svs_lock, flags);
-
-		svsb->phase = SVSB_PHASE_ERROR;
-		svs_adjust_pm_opp_volts(svsb);
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
 	}
 
 	ret = reset_control_assert(svsp->rst);
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
We need to disable svs function and restore DVFS opp voltages back to the
default voltages for making sure we have enough DVFS voltages.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index c4b36c908eda..3a2be5ced8e6 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1467,6 +1467,7 @@ static int svs_init02(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb;
 	unsigned long flags, time_left;
+	int ret;
 	u32 idx;
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
@@ -1485,7 +1486,8 @@ static int svs_init02(struct svs_platform *svsp)
 							msecs_to_jiffies(5000));
 		if (!time_left) {
 			dev_err(svsb->dev, "init02 completion timeout\n");
-			return -EBUSY;
+			ret = -EBUSY;
+			goto out_of_init02;
 		}
 	}
 
@@ -1503,12 +1505,21 @@ static int svs_init02(struct svs_platform *svsp)
 		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
 			if (svs_sync_bank_volts_from_opp(svsb)) {
 				dev_err(svsb->dev, "sync volt fail\n");
-				return -EPERM;
+				ret = -EPERM;
+				goto out_of_init02;
 			}
 		}
 	}
 
 	return 0;
+
+out_of_init02:
+	for (idx = 0; idx < svsp->bank_max; idx++) {
+		svsb = &svsp->banks[idx];
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
+	}
+
+	return ret;
 }
 
 static void svs_mon_mode(struct svs_platform *svsp)
-- 
2.18.0


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

* [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
We need to disable svs function and restore DVFS opp voltages back to the
default voltages for making sure we have enough DVFS voltages.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index c4b36c908eda..3a2be5ced8e6 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1467,6 +1467,7 @@ static int svs_init02(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb;
 	unsigned long flags, time_left;
+	int ret;
 	u32 idx;
 
 	for (idx = 0; idx < svsp->bank_max; idx++) {
@@ -1485,7 +1486,8 @@ static int svs_init02(struct svs_platform *svsp)
 							msecs_to_jiffies(5000));
 		if (!time_left) {
 			dev_err(svsb->dev, "init02 completion timeout\n");
-			return -EBUSY;
+			ret = -EBUSY;
+			goto out_of_init02;
 		}
 	}
 
@@ -1503,12 +1505,21 @@ static int svs_init02(struct svs_platform *svsp)
 		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
 			if (svs_sync_bank_volts_from_opp(svsb)) {
 				dev_err(svsb->dev, "sync volt fail\n");
-				return -EPERM;
+				ret = -EPERM;
+				goto out_of_init02;
 			}
 		}
 	}
 
 	return 0;
+
+out_of_init02:
+	for (idx = 0; idx < svsp->bank_max; idx++) {
+		svsb = &svsp->banks[idx];
+		svs_bank_disable_and_restore_default_volts(svsp, svsb);
+	}
+
+	return ret;
 }
 
 static void svs_mon_mode(struct svs_platform *svsp)
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 11/13] soc: mediatek: mtk-svs: add thermal voltage compensation if needed
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Some extreme test environment may keep IC temperature very low or very high
during system boot stage. For stability concern, we add thermal voltage
compenstation if needed no matter svs bank phase is in init02 or mon mode.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 3a2be5ced8e6..dacfee4a0b32 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -557,7 +557,7 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 	}
 
 	/* Get thermal effect */
-	if (svsb->phase == SVSB_PHASE_MON) {
+	if (!IS_ERR_OR_NULL(svsb->tzd)) {
 		ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
 		if (ret || (svsb->temp > SVSB_TEMP_UPPER_BOUND &&
 			    svsb->temp < SVSB_TEMP_LOWER_BOUND)) {
@@ -572,7 +572,8 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 			temp_voffset += svsb->tzone_ltemp_voffset;
 
 		/* 2-line bank update all opp volts when running mon mode */
-		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+		if (svsb->phase == SVSB_PHASE_MON && (svsb->type == SVSB_HIGH ||
+						      svsb->type == SVSB_LOW)) {
 			opp_start = 0;
 			opp_stop = svsb->opp_count;
 		}
@@ -588,11 +589,6 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 			/* do nothing */
 			goto unlock_mutex;
 		case SVSB_PHASE_INIT02:
-			svsb_volt = max(svsb->volt[i], svsb->vmin);
-			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
-							     svsb->volt_step,
-							     svsb->volt_base);
-			break;
 		case SVSB_PHASE_MON:
 			svsb_volt = max(svsb->volt[i] + temp_voffset, svsb->vmin);
 			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
@@ -1680,7 +1676,7 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
 			}
 		}
 
-		if (svsb->mode_support & SVSB_MODE_MON) {
+		if (!IS_ERR_OR_NULL(svsb->tzone_name)) {
 			svsb->tzd = thermal_zone_get_zone_by_name(svsb->tzone_name);
 			if (IS_ERR(svsb->tzd)) {
 				dev_err(svsb->dev, "cannot get \"%s\" thermal zone\n",
@@ -2124,6 +2120,7 @@ static struct svs_bank svs_mt8192_banks[] = {
 		.type			= SVSB_LOW,
 		.set_freq_pct		= svs_set_bank_freq_pct_v3,
 		.get_volts		= svs_get_bank_volts_v3,
+		.tzone_name		= "gpu1",
 		.volt_flags		= SVSB_REMOVE_DVTFIXED_VOLT,
 		.mode_support		= SVSB_MODE_INIT02,
 		.opp_count		= MAX_OPP_ENTRIES,
@@ -2141,6 +2138,10 @@ static struct svs_bank svs_mt8192_banks[] = {
 		.core_sel		= 0x0fff0100,
 		.int_st			= BIT(0),
 		.ctl0			= 0x00540003,
+		.tzone_htemp		= 85000,
+		.tzone_htemp_voffset	= 0,
+		.tzone_ltemp		= 25000,
+		.tzone_ltemp_voffset	= 7,
 	},
 	{
 		.sw_id			= SVSB_GPU,
-- 
2.18.0


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

* [PATCH v1 11/13] soc: mediatek: mtk-svs: add thermal voltage compensation if needed
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Some extreme test environment may keep IC temperature very low or very high
during system boot stage. For stability concern, we add thermal voltage
compenstation if needed no matter svs bank phase is in init02 or mon mode.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 3a2be5ced8e6..dacfee4a0b32 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -557,7 +557,7 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 	}
 
 	/* Get thermal effect */
-	if (svsb->phase == SVSB_PHASE_MON) {
+	if (!IS_ERR_OR_NULL(svsb->tzd)) {
 		ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
 		if (ret || (svsb->temp > SVSB_TEMP_UPPER_BOUND &&
 			    svsb->temp < SVSB_TEMP_LOWER_BOUND)) {
@@ -572,7 +572,8 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 			temp_voffset += svsb->tzone_ltemp_voffset;
 
 		/* 2-line bank update all opp volts when running mon mode */
-		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+		if (svsb->phase == SVSB_PHASE_MON && (svsb->type == SVSB_HIGH ||
+						      svsb->type == SVSB_LOW)) {
 			opp_start = 0;
 			opp_stop = svsb->opp_count;
 		}
@@ -588,11 +589,6 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
 			/* do nothing */
 			goto unlock_mutex;
 		case SVSB_PHASE_INIT02:
-			svsb_volt = max(svsb->volt[i], svsb->vmin);
-			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
-							     svsb->volt_step,
-							     svsb->volt_base);
-			break;
 		case SVSB_PHASE_MON:
 			svsb_volt = max(svsb->volt[i] + temp_voffset, svsb->vmin);
 			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
@@ -1680,7 +1676,7 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
 			}
 		}
 
-		if (svsb->mode_support & SVSB_MODE_MON) {
+		if (!IS_ERR_OR_NULL(svsb->tzone_name)) {
 			svsb->tzd = thermal_zone_get_zone_by_name(svsb->tzone_name);
 			if (IS_ERR(svsb->tzd)) {
 				dev_err(svsb->dev, "cannot get \"%s\" thermal zone\n",
@@ -2124,6 +2120,7 @@ static struct svs_bank svs_mt8192_banks[] = {
 		.type			= SVSB_LOW,
 		.set_freq_pct		= svs_set_bank_freq_pct_v3,
 		.get_volts		= svs_get_bank_volts_v3,
+		.tzone_name		= "gpu1",
 		.volt_flags		= SVSB_REMOVE_DVTFIXED_VOLT,
 		.mode_support		= SVSB_MODE_INIT02,
 		.opp_count		= MAX_OPP_ENTRIES,
@@ -2141,6 +2138,10 @@ static struct svs_bank svs_mt8192_banks[] = {
 		.core_sel		= 0x0fff0100,
 		.int_st			= BIT(0),
 		.ctl0			= 0x00540003,
+		.tzone_htemp		= 85000,
+		.tzone_htemp_voffset	= 0,
+		.tzone_ltemp		= 25000,
+		.tzone_ltemp_voffset	= 7,
 	},
 	{
 		.sw_id			= SVSB_GPU,
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 12/13] soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in svs_init01()
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Shang XiaoJing

From: Shang XiaoJing <shangxiaojing@huawei.com>

svs_init01() calls pm_runtime_get_sync() and added fail path as
svs_init01_finish to put usage_counter. However, pm_runtime_get_sync()
will increment usage_counter even it failed. Fix it by replacing it with
pm_runtime_resume_and_get() to keep usage counter balanced.

Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index dacfee4a0b32..af3a12e29e78 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1326,7 +1326,7 @@ static int svs_init01(struct svs_platform *svsp)
 				svsb->pm_runtime_enabled_count++;
 			}
 
-			ret = pm_runtime_get_sync(svsb->opp_dev);
+			ret = pm_runtime_resume_and_get(svsb->opp_dev);
 			if (ret < 0) {
 				dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
 				goto svs_init01_resume_cpuidle;
-- 
2.18.0


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

* [PATCH v1 12/13] soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in svs_init01()
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Shang XiaoJing

From: Shang XiaoJing <shangxiaojing@huawei.com>

svs_init01() calls pm_runtime_get_sync() and added fail path as
svs_init01_finish to put usage_counter. However, pm_runtime_get_sync()
will increment usage_counter even it failed. Fix it by replacing it with
pm_runtime_resume_and_get() to keep usage counter balanced.

Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index dacfee4a0b32..af3a12e29e78 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -1326,7 +1326,7 @@ static int svs_init01(struct svs_platform *svsp)
 				svsb->pm_runtime_enabled_count++;
 			}
 
-			ret = pm_runtime_get_sync(svsb->opp_dev);
+			ret = pm_runtime_resume_and_get(svsb->opp_dev);
 			if (ret < 0) {
 				dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
 				goto svs_init01_resume_cpuidle;
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
  2022-12-26  9:42 ` Roger Lu
@ 2022-12-26  9:42   ` Roger Lu
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Some projects might not support DEBUG_FS but still needs svs to be
supported. Therefore, keep svs alive even though debug cmd create fail.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index af3a12e29e78..c780a115543e 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
 	}
 
 	ret = svs_create_debug_cmds(svsp);
-	if (ret) {
+	if (ret)
 		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
-		goto svs_probe_iounmap;
-	}
 
 	return 0;
 
-- 
2.18.0


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

* [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
@ 2022-12-26  9:42   ` Roger Lu
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu @ 2022-12-26  9:42 UTC (permalink / raw)
  To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman, Nicolas Boichat
  Cc: Fan Chen, Roger Lu, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Some projects might not support DEBUG_FS but still needs svs to be
supported. Therefore, keep svs alive even though debug cmd create fail.

Signed-off-by: Roger Lu <roger.lu@mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index af3a12e29e78..c780a115543e 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
 	}
 
 	ret = svs_create_debug_cmds(svsp);
-	if (ret) {
+	if (ret)
 		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
-		goto svs_probe_iounmap;
-	}
 
 	return 0;
 
-- 
2.18.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> Some projects might not support DEBUG_FS but still needs svs to be
> supported. Therefore, keep svs alive even though debug cmd create fail.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> ---
>   drivers/soc/mediatek/mtk-svs.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> index af3a12e29e78..c780a115543e 100644
> --- a/drivers/soc/mediatek/mtk-svs.c
> +++ b/drivers/soc/mediatek/mtk-svs.c
> @@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
>   	}
>   

Instead of ignoring a planned failure, it's sensible to not fail at all:
enclose this call and the svs_create_debug_cmds() function in an ifdef.

#ifdef CONFIG_DEBUG_FS

>   	ret = svs_create_debug_cmds(svsp);
> -	if (ret) {
> +	if (ret)
>   		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
> -		goto svs_probe_iounmap;
> -	}

#endif

>   
>   	return 0;
>   
> 

Regards,
Angelo



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

* Re: [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> Some projects might not support DEBUG_FS but still needs svs to be
> supported. Therefore, keep svs alive even though debug cmd create fail.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> ---
>   drivers/soc/mediatek/mtk-svs.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> index af3a12e29e78..c780a115543e 100644
> --- a/drivers/soc/mediatek/mtk-svs.c
> +++ b/drivers/soc/mediatek/mtk-svs.c
> @@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
>   	}
>   

Instead of ignoring a planned failure, it's sensible to not fail at all:
enclose this call and the svs_create_debug_cmds() function in an ifdef.

#ifdef CONFIG_DEBUG_FS

>   	ret = svs_create_debug_cmds(svsp);
> -	if (ret) {
> +	if (ret)
>   		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
> -		goto svs_probe_iounmap;
> -	}

#endif

>   
>   	return 0;
>   
> 

Regards,
Angelo



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 12/13] soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in svs_init01()
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Shang XiaoJing

Il 26/12/22 10:42, Roger Lu ha scritto:
> From: Shang XiaoJing <shangxiaojing@huawei.com>
> 
> svs_init01() calls pm_runtime_get_sync() and added fail path as
> svs_init01_finish to put usage_counter. However, pm_runtime_get_sync()
> will increment usage_counter even it failed. Fix it by replacing it with
> pm_runtime_resume_and_get() to keep usage counter balanced.
> 
> Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
> Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



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

* Re: [PATCH v1 12/13] soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in svs_init01()
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group, Shang XiaoJing

Il 26/12/22 10:42, Roger Lu ha scritto:
> From: Shang XiaoJing <shangxiaojing@huawei.com>
> 
> svs_init01() calls pm_runtime_get_sync() and added fail path as
> svs_init01_finish to put usage_counter. However, pm_runtime_get_sync()
> will increment usage_counter even it failed. Fix it by replacing it with
> pm_runtime_resume_and_get() to keep usage counter balanced.
> 
> Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
> Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 11/13] soc: mediatek: mtk-svs: add thermal voltage compensation if needed
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> Some extreme test environment may keep IC temperature very low or very high
> during system boot stage. For stability concern, we add thermal voltage
> compenstation if needed no matter svs bank phase is in init02 or mon mode.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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


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

* Re: [PATCH v1 11/13] soc: mediatek: mtk-svs: add thermal voltage compensation if needed
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> Some extreme test environment may keep IC temperature very low or very high
> during system boot stage. For stability concern, we add thermal voltage
> compenstation if needed no matter svs bank phase is in init02 or mon mode.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 09/13] soc: mediatek: mtk-svs: use common function to disable restore voltages
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> The timing of disabling/restoring SVS bank is more than one place.
> Therefore, add a common function to use for removing the superfluous codes.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



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

* Re: [PATCH v1 09/13] soc: mediatek: mtk-svs: use common function to disable restore voltages
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> The timing of disabling/restoring SVS bank is more than one place.
> Therefore, add a common function to use for removing the superfluous codes.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 07/13] soc: mtk-svs: mt8183: refactor o_slope calculation
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> The o_slope value is dependent of the o_slope_sign, refactor code to get
> rid of unnecessary if constructs.
> 
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



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

* Re: [PATCH v1 07/13] soc: mtk-svs: mt8183: refactor o_slope calculation
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> The o_slope value is dependent of the o_slope_sign, refactor code to get
> rid of unnecessary if constructs.
> 
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
  2022-12-26  9:42   ` Roger Lu
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  -1 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
> We need to disable svs function and restore DVFS opp voltages back to the
> default voltages for making sure we have enough DVFS voltages.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

This needs a Fixes tag... and it also needs to apply to older kernels, as
MT8183 does use SVS in previous versions.

Perhaps you can send a different patch, without the cleanups, only for the
backport?
Otherwise you'll have to duplicate svs_bank_disable_and_restore_default_volts()
again before cleaning up...

I'll leave the choice to you.

Regards,
Angelo

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

* Re: [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
@ 2023-01-03 12:49     ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 44+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-01-03 12:49 UTC (permalink / raw)
  To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
	Nicolas Boichat
  Cc: Fan Chen, Jia-wei Chang, devicetree, linux-arm-kernel,
	linux-mediatek, linux-kernel, linux-pm,
	Project_Global_Chrome_Upstream_Group

Il 26/12/22 10:42, Roger Lu ha scritto:
> If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
> We need to disable svs function and restore DVFS opp voltages back to the
> default voltages for making sure we have enough DVFS voltages.
> 
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>

This needs a Fixes tag... and it also needs to apply to older kernels, as
MT8183 does use SVS in previous versions.

Perhaps you can send a different patch, without the cleanups, only for the
backport?
Otherwise you'll have to duplicate svs_bank_disable_and_restore_default_volts()
again before cleaning up...

I'll leave the choice to you.

Regards,
Angelo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
  2023-01-03 12:49     ` AngeloGioacchino Del Regno
@ 2023-01-10  5:30       ` Roger Lu (陸瑞傑)
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu (陸瑞傑) @ 2023-01-10  5:30 UTC (permalink / raw)
  To: eballetbo, matthias.bgg, khilman, angelogioacchino.delregno, drinkcat
  Cc: linux-kernel, linux-mediatek, devicetree, linux-pm,
	Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
	Jia-wei Chang (張佳偉),
	Fan Chen (陳凡)

Hi AngeloGioacchino,

Sorry for the late reply and thanks for the advices always.

On Tue, 2023-01-03 at 13:49 +0100, AngeloGioacchino Del Regno wrote:
> Il 26/12/22 10:42, Roger Lu ha scritto:
> > If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
> > We need to disable svs function and restore DVFS opp voltages back to the
> > default voltages for making sure we have enough DVFS voltages.
> > 
> > Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> 
> This needs a Fixes tag... and it also needs to apply to older kernels, as
> MT8183 does use SVS in previous versions.

No problem. I'll add a Fixes tag.

> 
> Perhaps you can send a different patch, without the cleanups, only for the
> backport?
> Otherwise you'll have to duplicate
> svs_bank_disable_and_restore_default_volts()
> again before cleaning up...
> 
> I'll leave the choice to you.


I'll reorder the patch to put cleanup patches first and fix patches next in the
patchset. Thanks for the advice again.

> 
> Regards,
> Angelo

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

* Re: [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail
@ 2023-01-10  5:30       ` Roger Lu (陸瑞傑)
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu (陸瑞傑) @ 2023-01-10  5:30 UTC (permalink / raw)
  To: eballetbo, matthias.bgg, khilman, angelogioacchino.delregno, drinkcat
  Cc: linux-kernel, linux-mediatek, devicetree, linux-pm,
	Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
	Jia-wei Chang (張佳偉),
	Fan Chen (陳凡)

Hi AngeloGioacchino,

Sorry for the late reply and thanks for the advices always.

On Tue, 2023-01-03 at 13:49 +0100, AngeloGioacchino Del Regno wrote:
> Il 26/12/22 10:42, Roger Lu ha scritto:
> > If svs init02 fail, it means we cannot rely on svs bank voltages anymore.
> > We need to disable svs function and restore DVFS opp voltages back to the
> > default voltages for making sure we have enough DVFS voltages.
> > 
> > Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> 
> This needs a Fixes tag... and it also needs to apply to older kernels, as
> MT8183 does use SVS in previous versions.

No problem. I'll add a Fixes tag.

> 
> Perhaps you can send a different patch, without the cleanups, only for the
> backport?
> Otherwise you'll have to duplicate
> svs_bank_disable_and_restore_default_volts()
> again before cleaning up...
> 
> I'll leave the choice to you.


I'll reorder the patch to put cleanup patches first and fix patches next in the
patchset. Thanks for the advice again.

> 
> Regards,
> Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
  2023-01-03 12:49     ` AngeloGioacchino Del Regno
@ 2023-01-10  5:35       ` Roger Lu (陸瑞傑)
  -1 siblings, 0 replies; 44+ messages in thread
From: Roger Lu (陸瑞傑) @ 2023-01-10  5:35 UTC (permalink / raw)
  To: eballetbo, matthias.bgg, khilman, angelogioacchino.delregno, drinkcat
  Cc: linux-kernel, linux-mediatek, devicetree, linux-pm,
	Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
	Jia-wei Chang (張佳偉),
	Fan Chen (陳凡)

Hi AngeloGioacchino,

Sorry for the late reply and thanks for the advices always.

On Tue, 2023-01-03 at 13:49 +0100, AngeloGioacchino Del Regno wrote:
> Il 26/12/22 10:42, Roger Lu ha scritto:
> > Some projects might not support DEBUG_FS but still needs svs to be
> > supported. Therefore, keep svs alive even though debug cmd create fail.
> > 
> > Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> > ---
> >   drivers/soc/mediatek/mtk-svs.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> > index af3a12e29e78..c780a115543e 100644
> > --- a/drivers/soc/mediatek/mtk-svs.c
> > +++ b/drivers/soc/mediatek/mtk-svs.c
> > @@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
> >   	}
> >   
> 
> Instead of ignoring a planned failure, it's sensible to not fail at all:
> enclose this call and the svs_create_debug_cmds() function in an ifdef.
> 
> #ifdef CONFIG_DEBUG_FS
> 
> >   	ret = svs_create_debug_cmds(svsp);
> > -	if (ret) {
> > +	if (ret)
> >   		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
> > -		goto svs_probe_iounmap;
> > -	}
> 
> #endif

Okay. I got it and will add ifdef CONFIG_DEBUG_FS in mtk-svs.c to make sure no
other side effects.

> 
> >   
> >   	return 0;
> >   
> > 
> 
> Regards,
> Angelo
> 
> 

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

* Re: [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail
@ 2023-01-10  5:35       ` Roger Lu (陸瑞傑)
  0 siblings, 0 replies; 44+ messages in thread
From: Roger Lu (陸瑞傑) @ 2023-01-10  5:35 UTC (permalink / raw)
  To: eballetbo, matthias.bgg, khilman, angelogioacchino.delregno, drinkcat
  Cc: linux-kernel, linux-mediatek, devicetree, linux-pm,
	Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
	Jia-wei Chang (張佳偉),
	Fan Chen (陳凡)

Hi AngeloGioacchino,

Sorry for the late reply and thanks for the advices always.

On Tue, 2023-01-03 at 13:49 +0100, AngeloGioacchino Del Regno wrote:
> Il 26/12/22 10:42, Roger Lu ha scritto:
> > Some projects might not support DEBUG_FS but still needs svs to be
> > supported. Therefore, keep svs alive even though debug cmd create fail.
> > 
> > Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> > ---
> >   drivers/soc/mediatek/mtk-svs.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> > index af3a12e29e78..c780a115543e 100644
> > --- a/drivers/soc/mediatek/mtk-svs.c
> > +++ b/drivers/soc/mediatek/mtk-svs.c
> > @@ -2390,10 +2390,8 @@ static int svs_probe(struct platform_device *pdev)
> >   	}
> >   
> 
> Instead of ignoring a planned failure, it's sensible to not fail at all:
> enclose this call and the svs_create_debug_cmds() function in an ifdef.
> 
> #ifdef CONFIG_DEBUG_FS
> 
> >   	ret = svs_create_debug_cmds(svsp);
> > -	if (ret) {
> > +	if (ret)
> >   		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
> > -		goto svs_probe_iounmap;
> > -	}
> 
> #endif

Okay. I got it and will add ifdef CONFIG_DEBUG_FS in mtk-svs.c to make sure no
other side effects.

> 
> >   
> >   	return 0;
> >   
> > 
> 
> Regards,
> Angelo
> 
> 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

end of thread, other threads:[~2023-01-10  5:57 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-26  9:42 [PATCH v1 0/13] Enahance SVS's robustness Roger Lu
2022-12-26  9:42 ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 01/13] soc: mediatek: mtk-svs: enable the IRQ later Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 02/13] soc: mediatek: mtk-svs: clean up platform probing Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 03/13] soc: mediatek: mtk-svs: improve readability of platform_probe Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 04/13] soc: mediatek: mtk-svs: move svs_platform_probe into probe Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 05/13] soc: mediatek: mtk-svs: delete superfluous platform data entries Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 06/13] soc: mediatek: mtk-svs: use svs get efuse common function Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 07/13] soc: mtk-svs: mt8183: refactor o_slope calculation Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2022-12-26  9:42 ` [PATCH v1 08/13] soc: mediatek: mtk-svs: add main_clk check during system-wide suspend Roger Lu
2022-12-26  9:42   ` Roger Lu
2022-12-26  9:42 ` [PATCH v1 09/13] soc: mediatek: mtk-svs: use common function to disable restore voltages Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2022-12-26  9:42 ` [PATCH v1 10/13] soc: mediatek: mtk-svs: restore default voltages when svs init02 fail Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2023-01-10  5:30     ` Roger Lu (陸瑞傑)
2023-01-10  5:30       ` Roger Lu (陸瑞傑)
2022-12-26  9:42 ` [PATCH v1 11/13] soc: mediatek: mtk-svs: add thermal voltage compensation if needed Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2022-12-26  9:42 ` [PATCH v1 12/13] soc: mediatek: mtk-svs: Use pm_runtime_resume_and_get() in svs_init01() Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2022-12-26  9:42 ` [PATCH v1 13/13] soc: mediatek: mtk-svs: keep svs alive even though debug cmd create fail Roger Lu
2022-12-26  9:42   ` Roger Lu
2023-01-03 12:49   ` AngeloGioacchino Del Regno
2023-01-03 12:49     ` AngeloGioacchino Del Regno
2023-01-10  5:35     ` Roger Lu (陸瑞傑)
2023-01-10  5:35       ` Roger Lu (陸瑞傑)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.