[PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[Zoie Lin]

Introduce support for runtime PM operations in
the I2C driver, enabling runtime suspend and resume functionality.

Although in most platforms, the bus power of i2c is always
on, some platforms disable the i2c bus power in order to meet
low power request.

This implementation includes bus regulator control to facilitate
proper handling of the bus power based on platform requirements.

Signed-off-by: Zoie Lin <zoie.lin@mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 73 +++++++++++++++++++++++++++------
 1 file changed, 61 insertions(+), 12 deletions(-)

This series is based on linux-next, tag: next-20250210

Changes in v4:
- Removed unnecessary variable initialization.
- Removed unnecessary brackets.
- Corrected grammar issues in the commit message.
- Confirmed autosuspend delay is not necessary.

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 5bd342047d59..1979b46d75f0 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -21,6 +21,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/scatterlist.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
@@ -1245,8 +1246,8 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 	int left_num = num;
 	struct mtk_i2c *i2c = i2c_get_adapdata(adap);
 
-	ret = clk_bulk_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
-	if (ret)
+	ret = pm_runtime_resume_and_get(i2c->dev);
+	if (ret < 0)
 		return ret;
 
 	i2c->auto_restart = i2c->dev_comp->auto_restart;
@@ -1299,7 +1300,9 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 	ret = num;
 
 err_exit:
-	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	pm_runtime_mark_last_busy(i2c->dev);
+	pm_runtime_put_sync(i2c->dev);
+
 	return ret;
 }
 
@@ -1370,6 +1373,38 @@ static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c)
 	return 0;
 }
 
+static int mtk_i2c_runtime_suspend(struct device *dev)
+{
+	struct mtk_i2c *i2c = dev_get_drvdata(dev);
+
+	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	if (i2c->adap.bus_regulator)
+		regulator_disable(i2c->adap.bus_regulator);
+
+	return 0;
+}
+
+static int mtk_i2c_runtime_resume(struct device *dev)
+{
+	int ret;
+	struct mtk_i2c *i2c = dev_get_drvdata(dev);
+
+	if (i2c->adap.bus_regulator) {
+		ret = regulator_enable(i2c->adap.bus_regulator);
+		if (ret) {
+			dev_err(dev, "enable regulator failed!\n");
+			return ret;
+		}
+	}
+
+	ret = clk_bulk_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	if (ret)
+		if (i2c->adap.bus_regulator)
+			regulator_disable(i2c->adap.bus_regulator);
+
+	return ret;
+}
+
 static int mtk_i2c_probe(struct platform_device *pdev)
 {
 	int ret = 0;
@@ -1472,13 +1507,18 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 		}
 	}
 
-	ret = clk_bulk_prepare_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	ret = clk_bulk_prepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
 	if (ret) {
-		dev_err(&pdev->dev, "clock enable failed!\n");
 		return ret;
 	}
+
+	platform_set_drvdata(pdev, i2c);
+
+	ret = mtk_i2c_runtime_resume(i2c->dev);
+	if (ret < 0)
+		goto err_clk_bulk_unprepare;
 	mtk_i2c_init_hw(i2c);
-	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	mtk_i2c_runtime_suspend(i2c->dev);
 
 	ret = devm_request_irq(&pdev->dev, irq, mtk_i2c_irq,
 			       IRQF_NO_SUSPEND | IRQF_TRIGGER_NONE,
@@ -1486,19 +1526,20 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"Request I2C IRQ %d fail\n", irq);
-		goto err_bulk_unprepare;
+		goto err_clk_bulk_unprepare;
 	}
+	pm_runtime_enable(&pdev->dev);
 
 	i2c_set_adapdata(&i2c->adap, i2c);
 	ret = i2c_add_adapter(&i2c->adap);
 	if (ret)
-		goto err_bulk_unprepare;
-
-	platform_set_drvdata(pdev, i2c);
+		goto err_pm_runtime_disable;
 
 	return 0;
 
-err_bulk_unprepare:
+err_pm_runtime_disable:
+	pm_runtime_disable(&pdev->dev);
+err_clk_bulk_unprepare:
 	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
 
 	return ret;
@@ -1510,6 +1551,7 @@ static void mtk_i2c_remove(struct platform_device *pdev)
 
 	i2c_del_adapter(&i2c->adap);
 
+	pm_runtime_disable(&pdev->dev);
 	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
 }
 
@@ -1518,6 +1560,10 @@ static int mtk_i2c_suspend_noirq(struct device *dev)
 	struct mtk_i2c *i2c = dev_get_drvdata(dev);
 
 	i2c_mark_adapter_suspended(&i2c->adap);
+
+	if (!pm_runtime_status_suspended(dev))
+		mtk_i2c_runtime_suspend(dev);
+
 	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
 
 	return 0;
@@ -1536,7 +1582,8 @@ static int mtk_i2c_resume_noirq(struct device *dev)
 
 	mtk_i2c_init_hw(i2c);
 
-	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
+	if (pm_runtime_status_suspended(dev))
+		mtk_i2c_runtime_resume(dev);
 
 	i2c_mark_adapter_resumed(&i2c->adap);
 
@@ -1546,6 +1593,8 @@ static int mtk_i2c_resume_noirq(struct device *dev)
 static const struct dev_pm_ops mtk_i2c_pm = {
 	NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_i2c_suspend_noirq,
 				  mtk_i2c_resume_noirq)
+	SET_RUNTIME_PM_OPS(mtk_i2c_runtime_suspend, mtk_i2c_runtime_resume,
+			   NULL)
 };
 
 static struct platform_driver mtk_i2c_driver = {
-- 
2.45.2

Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[Andi Shyti]

Hi Zoie,

my comment was on the [PATCH v3 ...], this should have been
[PATCH v4 1/1]. If you use git-format-patch, most probably you
will get it right.

If you have more than one patch, you can use the --cover-letter.
option to get the patch 0/X.

On Tue, Feb 11, 2025 at 10:39:37PM +0800, Zoie Lin wrote:
> Introduce support for runtime PM operations in
> the I2C driver, enabling runtime suspend and resume functionality.
> 
> Although in most platforms, the bus power of i2c is always
> on, some platforms disable the i2c bus power in order to meet
> low power request.
> 
> This implementation includes bus regulator control to facilitate
> proper handling of the bus power based on platform requirements.
> 
> Signed-off-by: Zoie Lin <zoie.lin@mediatek.com>

Is it possible to have an ack from Qii?

> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 73 +++++++++++++++++++++++++++------
>  1 file changed, 61 insertions(+), 12 deletions(-)
> 
> This series is based on linux-next, tag: next-20250210
> 
> Changes in v4:

what about the previous versions?

> - Removed unnecessary variable initialization.
> - Removed unnecessary brackets.
> - Corrected grammar issues in the commit message.
> - Confirmed autosuspend delay is not necessary.
> 

...

> @@ -1472,13 +1507,18 @@ static int mtk_i2c_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	ret = clk_bulk_prepare_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	ret = clk_bulk_prepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
>  	if (ret) {
> -		dev_err(&pdev->dev, "clock enable failed!\n");

Why have you removed this dev_err? You coulde have rather changed
it to match the error. While at it you could also replace it with
dev_err_probe()

The rest looks good to me, I'll be happy if you can have an ack
from Qii.

Andi

>  		return ret;

Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[AngeloGioacchino Del Regno]

Il 11/02/25 15:39, Zoie Lin ha scritto:
> Introduce support for runtime PM operations in
> the I2C driver, enabling runtime suspend and resume functionality.
> 
> Although in most platforms, the bus power of i2c is always
> on, some platforms disable the i2c bus power in order to meet
> low power request.
> 
> This implementation includes bus regulator control to facilitate
> proper handling of the bus power based on platform requirements.
> 
> Signed-off-by: Zoie Lin <zoie.lin@mediatek.com>
> ---
>   drivers/i2c/busses/i2c-mt65xx.c | 73 +++++++++++++++++++++++++++------
>   1 file changed, 61 insertions(+), 12 deletions(-)
> 
> This series is based on linux-next, tag: next-20250210
> 
> Changes in v4:
> - Removed unnecessary variable initialization.
> - Removed unnecessary brackets.
> - Corrected grammar issues in the commit message.
> - Confirmed autosuspend delay is not necessary.

Turning on and off regulators at start of transfer and end of transfer respectively
is very expensive and, while it makes sense for power efficiency of the controller,
it doesn't make sense for:

  1. Responsiveness (latency); and
  2. Platform power efficiency at a whole.

As a start, just set the autosuspend delay to 250ms; this gives you at least time
to bring up clocks and regulators and usually finish a transfer at 400KHz, giving
you the chance to also get some more requests before autosuspend decides to, well,
auto..suspend the device.

The right way of choosing an autosuspend delay a bit more precisely, though, for
this device, would be to check the bus speed and calculate the autosuspend time
accordingly.

Cheers,
Angelo

> 
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 5bd342047d59..1979b46d75f0 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -21,6 +21,7 @@
>   #include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>   #include <linux/scatterlist.h>
>   #include <linux/sched.h>
>   #include <linux/slab.h>
> @@ -1245,8 +1246,8 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>   	int left_num = num;
>   	struct mtk_i2c *i2c = i2c_get_adapdata(adap);
>   
> -	ret = clk_bulk_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> -	if (ret)
> +	ret = pm_runtime_resume_and_get(i2c->dev);
> +	if (ret < 0)
>   		return ret;
>   
>   	i2c->auto_restart = i2c->dev_comp->auto_restart;
> @@ -1299,7 +1300,9 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>   	ret = num;
>   
>   err_exit:
> -	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	pm_runtime_mark_last_busy(i2c->dev);
> +	pm_runtime_put_sync(i2c->dev);
> +
>   	return ret;
>   }
>   
> @@ -1370,6 +1373,38 @@ static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c)
>   	return 0;
>   }
>   
> +static int mtk_i2c_runtime_suspend(struct device *dev)
> +{
> +	struct mtk_i2c *i2c = dev_get_drvdata(dev);
> +
> +	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	if (i2c->adap.bus_regulator)
> +		regulator_disable(i2c->adap.bus_regulator);
> +
> +	return 0;
> +}
> +
> +static int mtk_i2c_runtime_resume(struct device *dev)
> +{
> +	int ret;
> +	struct mtk_i2c *i2c = dev_get_drvdata(dev);
> +
> +	if (i2c->adap.bus_regulator) {
> +		ret = regulator_enable(i2c->adap.bus_regulator);
> +		if (ret) {
> +			dev_err(dev, "enable regulator failed!\n");
> +			return ret;
> +		}
> +	}
> +
> +	ret = clk_bulk_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	if (ret)
> +		if (i2c->adap.bus_regulator)
> +			regulator_disable(i2c->adap.bus_regulator);
> +
> +	return ret;
> +}
> +
>   static int mtk_i2c_probe(struct platform_device *pdev)
>   {
>   	int ret = 0;
> @@ -1472,13 +1507,18 @@ static int mtk_i2c_probe(struct platform_device *pdev)
>   		}
>   	}
>   
> -	ret = clk_bulk_prepare_enable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	ret = clk_bulk_prepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
>   	if (ret) {
> -		dev_err(&pdev->dev, "clock enable failed!\n");
>   		return ret;
>   	}
> +
> +	platform_set_drvdata(pdev, i2c);
> +
> +	ret = mtk_i2c_runtime_resume(i2c->dev);
> +	if (ret < 0)
> +		goto err_clk_bulk_unprepare;
>   	mtk_i2c_init_hw(i2c);
> -	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	mtk_i2c_runtime_suspend(i2c->dev);
>   
>   	ret = devm_request_irq(&pdev->dev, irq, mtk_i2c_irq,
>   			       IRQF_NO_SUSPEND | IRQF_TRIGGER_NONE,
> @@ -1486,19 +1526,20 @@ static int mtk_i2c_probe(struct platform_device *pdev)
>   	if (ret < 0) {
>   		dev_err(&pdev->dev,
>   			"Request I2C IRQ %d fail\n", irq);
> -		goto err_bulk_unprepare;
> +		goto err_clk_bulk_unprepare;
>   	}
> +	pm_runtime_enable(&pdev->dev);
>   
>   	i2c_set_adapdata(&i2c->adap, i2c);
>   	ret = i2c_add_adapter(&i2c->adap);
>   	if (ret)
> -		goto err_bulk_unprepare;
> -
> -	platform_set_drvdata(pdev, i2c);
> +		goto err_pm_runtime_disable;
>   
>   	return 0;
>   
> -err_bulk_unprepare:
> +err_pm_runtime_disable:
> +	pm_runtime_disable(&pdev->dev);
> +err_clk_bulk_unprepare:
>   	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
>   
>   	return ret;
> @@ -1510,6 +1551,7 @@ static void mtk_i2c_remove(struct platform_device *pdev)
>   
>   	i2c_del_adapter(&i2c->adap);
>   
> +	pm_runtime_disable(&pdev->dev);
>   	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
>   }
>   
> @@ -1518,6 +1560,10 @@ static int mtk_i2c_suspend_noirq(struct device *dev)
>   	struct mtk_i2c *i2c = dev_get_drvdata(dev);
>   
>   	i2c_mark_adapter_suspended(&i2c->adap);
> +
> +	if (!pm_runtime_status_suspended(dev))
> +		mtk_i2c_runtime_suspend(dev);
> +
>   	clk_bulk_unprepare(I2C_MT65XX_CLK_MAX, i2c->clocks);
>   
>   	return 0;
> @@ -1536,7 +1582,8 @@ static int mtk_i2c_resume_noirq(struct device *dev)
>   
>   	mtk_i2c_init_hw(i2c);
>   
> -	clk_bulk_disable(I2C_MT65XX_CLK_MAX, i2c->clocks);
> +	if (pm_runtime_status_suspended(dev))
> +		mtk_i2c_runtime_resume(dev);
>   
>   	i2c_mark_adapter_resumed(&i2c->adap);
>   
> @@ -1546,6 +1593,8 @@ static int mtk_i2c_resume_noirq(struct device *dev)
>   static const struct dev_pm_ops mtk_i2c_pm = {
>   	NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_i2c_suspend_noirq,
>   				  mtk_i2c_resume_noirq)
> +	SET_RUNTIME_PM_OPS(mtk_i2c_runtime_suspend, mtk_i2c_runtime_resume,
> +			   NULL)
>   };
>   
>   static struct platform_driver mtk_i2c_driver = {

Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[Zoie Lin (林禹妡)]

Hi Angelo,

Thank you for your suggestions regarding the autosuspend delay.

We understand the importance of balancing power efficiency and
responsiveness. Given the diversity of I2C devices connected
under each platform, it is indeed challenging to estimate an
appropriate delay time for testing.

Therefore, we would like to proceed with your initial suggestion
and set the autosuspend delay to 250ms. Based on our preliminary
tests, this adjustment appears to be a practical solution across 
our existing platforms.

Thank you.

Best regards,
Zoie


On Thu, 2025-02-13 at 12:57 +0100, AngeloGioacchino Del Regno wrote:
> 
> 
> Turning on and off regulators at start of transfer and end of
> transfer respectively
> is very expensive and, while it makes sense for power efficiency of
> the controller,
> it doesn't make sense for:
> 
>   1. Responsiveness (latency); and
>   2. Platform power efficiency at a whole.
> 
> As a start, just set the autosuspend delay to 250ms; this gives you
> at least time
> to bring up clocks and regulators and usually finish a transfer at
> 400KHz, giving
> you the chance to also get some more requests before autosuspend
> decides to, well,
> auto..suspend the device.
> 
> The right way of choosing an autosuspend delay a bit more precisely,
> though, for
> this device, would be to check the bus speed and calculate the
> autosuspend time
> accordingly.
> 
> Cheers,
> Angelo
> 
> 
> 

Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

[Andi Shyti]

Hi Zoie,

On Tue, Mar 04, 2025 at 08:37:27AM +0000, Zoie Lin (林禹妡) wrote:
> 
> ...
> 
> On Thu, 2025-02-13 at 12:57 +0100, AngeloGioacchino Del Regno wrote:
> > 
> > 
> > Turning on and off regulators at start of transfer and end of
> > transfer respectively
> > is very expensive and, while it makes sense for power efficiency of
> > the controller,
> > it doesn't make sense for:
> > 
> >   1. Responsiveness (latency); and
> >   2. Platform power efficiency at a whole.
> > 
> > As a start, just set the autosuspend delay to 250ms; this gives you
> > at least time
> > to bring up clocks and regulators and usually finish a transfer at
> > 400KHz, giving
> > you the chance to also get some more requests before autosuspend
> > decides to, well,
> > auto..suspend the device.
> > 
> > The right way of choosing an autosuspend delay a bit more precisely,
> > though, for
> > this device, would be to check the bus speed and calculate the
> > autosuspend time
> > accordingly.
> 
> We understand the importance of balancing power efficiency and
> responsiveness. Given the diversity of I2C devices connected
> under each platform, it is indeed challenging to estimate an
> appropriate delay time for testing.
> 
> Therefore, we would like to proceed with your initial suggestion
> and set the autosuspend delay to 250ms. Based on our preliminary
> tests, this adjustment appears to be a practical solution across 
> our existing platforms.

Am I understanding correctly that you are planning a v2?

Andi