Re: [RFT][PATCH 1/2] i2c: designware: Clean up PM handling in dw_i2c_plat_probe()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

On 09/04/2017 02:08 AM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>

The power management handling in dw_i2c_plat_probe() is somewhat
messy and it is rather hard to figure out the code intention for
the case when pm_disabled is set.  In that case, the driver doesn't
enable runtime PM at all, but in addition to that it calls
pm_runtime_forbid() as though it wasn't sure if runtime PM might
be enabled for the device later by someone else.

Although that concern doesn't seem to be actually valid, the
device is clearly still expected to be PM-capable even in the
pm_disabled set case, so a better approach would be to enable
runtime PM for it unconditionally and then prevent it from
being runtime suspended by using pm_runtime_forbid().

Make the driver do that as that will help to clean up its system
sleep handling in a relatively straightforward way.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
---
  drivers/i2c/busses/i2c-designware-platdrv.c |   36 +++++++++++++++++++---------
  1 file changed, 25 insertions(+), 11 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===================================================================
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -249,6 +249,16 @@ static void dw_i2c_set_fifo_size(struct
  	}
  }
+static void dw_i2c_plat_pm_cleanup(struct dw_i2c_dev *dev)
+{
+	pm_runtime_get_noresume(dev->dev);
+	if (dev->pm_disabled)
+		pm_runtime_allow(dev->dev);
+
+	pm_runtime_disable(dev->dev);
+	pm_runtime_put_noidle(dev->dev);
+}
+
  static int dw_i2c_plat_probe(struct platform_device *pdev)
  {
  	struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
@@ -362,14 +372,19 @@ static int dw_i2c_plat_probe(struct plat
  	ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
  	adap->dev.of_node = pdev->dev.of_node;
- if (dev->pm_disabled) {
+	/* The code below assumes runtime PM to be disabled. */
+	WARN_ON(pm_runtime_enabled(&pdev->dev));
+
+	pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+	if (dev->pm_disabled)
  		pm_runtime_forbid(&pdev->dev);
-	} else {
-		pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
-		pm_runtime_use_autosuspend(&pdev->dev);
-		pm_runtime_set_active(&pdev->dev);
-		pm_runtime_enable(&pdev->dev);
-	}
+
+	pm_runtime_put_noidle(&pdev->dev);
Is pm_runtime_get_noresume()/pm_runtime_put_noidle() cycle needed here? My vague memory tells platform device won't power off instantly because of plain pm_runtime_enable() even if dev->power.usage_count is zero.

I guess it was the pm_request_idle() in driver_probe_device() that triggered the power transition after probe.

drivers/base/dd.c: driver_probe_device():
	pm_runtime_barrier(dev);
	ret = really_probe(dev, drv);
	pm_request_idle(dev);

--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux