[PATCH 0/7] PM runtime regression fixes for omaps

[PATCH 0/7] PM runtime regression fixes for omaps

[Tony Lindgren]

Hi all,

Here are some PM runtime regression fixes for omaps after recent
pm_runtime_reinit changes.

We basically have to use pm_runtime_put_sync_suspend() or
a combination of pm_runtime_dont_use_autosuspend() and
pm_runtime_put_sync() if the driver has enabled autoidle.

If no objections, I'd like to merge this whole series via
the ARM SoC tree.

Regards,

Tony


Tony Lindgren (7):
  mmc: omap_hsmmc: Fix PM regression with deferred probe for
    pm_runtime_reinit
  i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit
  spi: omap2-mcspi: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: 8250_omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  ARM: OMAP2+: Improve omap_device error for driver writers
  ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

 arch/arm/mach-omap2/omap_device.c   | 14 +++++++++++++-
 drivers/i2c/busses/i2c-omap.c       |  4 +++-
 drivers/mmc/host/omap_hsmmc.c       |  6 ++++--
 drivers/spi/spi-omap2-mcspi.c       |  3 +++
 drivers/tty/serial/8250/8250_omap.c |  4 +++-
 drivers/tty/serial/omap-serial.c    |  4 +++-
 6 files changed, 29 insertions(+), 6 deletions(-)

-- 
2.7.0

[PATCH 0/7] PM runtime regression fixes for omaps

[Tony Lindgren]

Hi all,

Here are some PM runtime regression fixes for omaps after recent
pm_runtime_reinit changes.

We basically have to use pm_runtime_put_sync_suspend() or
a combination of pm_runtime_dont_use_autosuspend() and
pm_runtime_put_sync() if the driver has enabled autoidle.

If no objections, I'd like to merge this whole series via
the ARM SoC tree.

Regards,

Tony


Tony Lindgren (7):
  mmc: omap_hsmmc: Fix PM regression with deferred probe for
    pm_runtime_reinit
  i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit
  spi: omap2-mcspi: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: 8250_omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  ARM: OMAP2+: Improve omap_device error for driver writers
  ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

 arch/arm/mach-omap2/omap_device.c   | 14 +++++++++++++-
 drivers/i2c/busses/i2c-omap.c       |  4 +++-
 drivers/mmc/host/omap_hsmmc.c       |  6 ++++--
 drivers/spi/spi-omap2-mcspi.c       |  3 +++
 drivers/tty/serial/8250/8250_omap.c |  4 +++-
 drivers/tty/serial/omap-serial.c    |  4 +++-
 6 files changed, 29 insertions(+), 6 deletions(-)

-- 
2.7.0

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Ulf, I'd like to merge this along with other related fixes via the
ARM SoC tree if no objections, please review and ack if this look OK
to you.

---
 drivers/mmc/host/omap_hsmmc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b6639ea..32bc112 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
 	int ret;
 
 	/* Disable the clocks */
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);
@@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	return 0;
 }
 
-- 
2.7.0

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Ulf, I'd like to merge this along with other related fixes via the
ARM SoC tree if no objections, please review and ack if this look OK
to you.

---
 drivers/mmc/host/omap_hsmmc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b6639ea..32bc112 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
 	int ret;
 
 	/* Disable the clocks */
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);
@@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	return 0;
 }
 
-- 
2.7.0

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-i2c@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Wolfram, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---

 drivers/i2c/busses/i2c-omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 08d26ba..13c4529 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
 
 err_unuse_clocks:
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
-	pm_runtime_put(omap->dev);
+	pm_runtime_dont_use_autosuspend(omap->dev);
+	pm_runtime_put_sync(omap->dev);
 	pm_runtime_disable(&pdev->dev);
 err_free_mem:
 
@@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
 		return ret;
 
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return 0;
-- 
2.7.0

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-i2c at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Wolfram, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---

 drivers/i2c/busses/i2c-omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 08d26ba..13c4529 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
 
 err_unuse_clocks:
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
-	pm_runtime_put(omap->dev);
+	pm_runtime_dont_use_autosuspend(omap->dev);
+	pm_runtime_put_sync(omap->dev);
 	pm_runtime_disable(&pdev->dev);
 err_free_mem:
 
@@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
 		return ret;
 
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return 0;
-- 
2.7.0

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-spi@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Mark, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---
 drivers/spi/spi-omap2-mcspi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 7273820..0caa3c8 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
 	return status;
 
 disable_pm:
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 free_master:
 	spi_master_put(master);
@@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
 	struct spi_master *master = platform_get_drvdata(pdev);
 	struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
 
+	pm_runtime_dont_use_autosuspend(mcspi->dev);
 	pm_runtime_put_sync(mcspi->dev);
 	pm_runtime_disable(&pdev->dev);
 
-- 
2.7.0

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-spi at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Mark, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---
 drivers/spi/spi-omap2-mcspi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 7273820..0caa3c8 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
 	return status;
 
 disable_pm:
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 free_master:
 	spi_master_put(master);
@@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
 	struct spi_master *master = platform_get_drvdata(pdev);
 	struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
 
+	pm_runtime_dont_use_autosuspend(mcspi->dev);
 	pm_runtime_put_sync(mcspi->dev);
 	pm_runtime_disable(&pdev->dev);
 
-- 
2.7.0

[PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if this
look OK to you.

---
 drivers/tty/serial/8250/8250_omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index a2c0734..81ff337 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
 	pm_runtime_put_autosuspend(&pdev->dev);
 	return 0;
 err:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return ret;
 }
@@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
 {
 	struct omap8250_priv *priv = platform_get_drvdata(pdev);
 
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	serial8250_unregister_port(priv->line);
-- 
2.7.0

[PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if this
look OK to you.

---
 drivers/tty/serial/8250/8250_omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index a2c0734..81ff337 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
 	pm_runtime_put_autosuspend(&pdev->dev);
 	return 0;
 err:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return ret;
 }
@@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
 {
 	struct omap8250_priv *priv = platform_get_drvdata(pdev);
 
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	serial8250_unregister_port(priv->line);
-- 
2.7.0

[PATCH 5/7] serial: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if
this look OK to you.

---
 drivers/tty/serial/omap-serial.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b645f92..5c43f75 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 	return 0;
 
 err_add_port:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	pm_qos_remove_request(&up->pm_qos_request);
 	device_init_wakeup(up->dev, false);
@@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
 {
 	struct uart_omap_port *up = platform_get_drvdata(dev);
 
+	pm_runtime_dont_use_autosuspend(up->dev);
 	pm_runtime_put_sync(up->dev);
 	pm_runtime_disable(up->dev);
 	uart_remove_one_port(&serial_omap_reg, &up->port);
-- 
2.7.0

[PATCH 5/7] serial: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if
this look OK to you.

---
 drivers/tty/serial/omap-serial.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b645f92..5c43f75 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 	return 0;
 
 err_add_port:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	pm_qos_remove_request(&up->pm_qos_request);
 	device_init_wakeup(up->dev, false);
@@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
 {
 	struct uart_omap_port *up = platform_get_drvdata(dev);
 
+	pm_runtime_dont_use_autosuspend(up->dev);
 	pm_runtime_put_sync(up->dev);
 	pm_runtime_disable(up->dev);
 	uart_remove_one_port(&serial_omap_reg, &up->port);
-- 
2.7.0

[PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Tony Lindgren]

Drivers using pm_runtime_use_autosuspend() may not get disabled after
-EPROBE_DEFER. On the following device driver probe, hardware state
is different from the PM runtime state causing omap_device to produce
the following error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

Let's add a proper error message so driver writers can easily fix
their drivers for PM.

In general, the solution is to fix the drivers to follow the PM
runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Let's not return with 0 from _od_runtime_resume() as that will
eventually lead into new drivers with broken PM runtime that will
block deeper idle states on omaps.

Cc: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/mach-omap2/omap_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 0437537..ebd8369 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
 	int ret;
 
 	ret = omap_device_enable(pdev);
-	if (ret)
+	if (ret) {
+		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
 		return ret;
+	}
 
 	return pm_generic_runtime_resume(dev);
 }
-- 
2.7.0

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

[PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Tony Lindgren]

Drivers using pm_runtime_use_autosuspend() may not get disabled after
-EPROBE_DEFER. On the following device driver probe, hardware state
is different from the PM runtime state causing omap_device to produce
the following error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

Let's add a proper error message so driver writers can easily fix
their drivers for PM.

In general, the solution is to fix the drivers to follow the PM
runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Let's not return with 0 from _od_runtime_resume() as that will
eventually lead into new drivers with broken PM runtime that will
block deeper idle states on omaps.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 0437537..ebd8369 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
 	int ret;
 
 	ret = omap_device_enable(pdev);
-	if (ret)
+	if (ret) {
+		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
 		return ret;
+	}
 
 	return pm_generic_runtime_resume(dev);
 }
-- 
2.7.0

[PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Tony Lindgren]

If a driver PM runtime is disabled via sysfs, and the module is
unloaded, PM runtime can't do anything to disable the device. Let's
let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.

Otherwise omap_device will produce and error on the following module
reload. This can be easily tested with something like:

# modprobe omap_hsmmc
# echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
# rmmod omap_hsmmc
# modprobe omap_hsmmc

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index ebd8369..f7ff3b9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od;
+	int err;
 
 	switch (event) {
 	case BUS_NOTIFY_DEL_DEVICE:
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		od = to_omap_device(pdev);
+		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
+			dev_info(dev, "enabled after unload, idling\n");
+			err = omap_device_idle(pdev);
+			if (err)
+				dev_err(dev, "failed to idle\n");
+		}
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-- 
2.7.0

[PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Tony Lindgren]

If a driver PM runtime is disabled via sysfs, and the module is
unloaded, PM runtime can't do anything to disable the device. Let's
let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.

Otherwise omap_device will produce and error on the following module
reload. This can be easily tested with something like:

# modprobe omap_hsmmc
# echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
# rmmod omap_hsmmc
# modprobe omap_hsmmc

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index ebd8369..f7ff3b9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od;
+	int err;
 
 	switch (event) {
 	case BUS_NOTIFY_DEL_DEVICE:
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		od = to_omap_device(pdev);
+		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
+			dev_info(dev, "enabled after unload, idling\n");
+			err = omap_device_idle(pdev);
+			if (err)
+				dev_err(dev, "failed to idle\n");
+		}
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-- 
2.7.0

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> Ulf, I'd like to merge this along with other related fixes via the
> ARM SoC tree if no objections, please review and ack if this look OK
> to you.

I have some other omap_hsmmc patches queued for 4.6, so I prefer to
send this via my mmc tree.

I guess that's okay as well!?

>
> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b6639ea..32bc112 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
>         int ret;
>
>         /* Disable the clocks */
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect.

The mmc core holds a runtime PM usage count for the device anyway, so
the clock won't be disabled.
Please remove this change from the patch.

>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);
> @@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect, as the PM core prevents runtime suspend during the
system PM phase.
It does so, by increasing the runtime PM usage count
(pm_runtime_get_noresume()).

Please remove this change from patch.

>         return 0;
>  }
>
> --
> 2.7.0
>

Kind regards
Uffe

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> Ulf, I'd like to merge this along with other related fixes via the
> ARM SoC tree if no objections, please review and ack if this look OK
> to you.

I have some other omap_hsmmc patches queued for 4.6, so I prefer to
send this via my mmc tree.

I guess that's okay as well!?

>
> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b6639ea..32bc112 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
>         int ret;
>
>         /* Disable the clocks */
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect.

The mmc core holds a runtime PM usage count for the device anyway, so
the clock won't be disabled.
Please remove this change from the patch.

>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);
> @@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect, as the PM core prevents runtime suspend during the
system PM phase.
It does so, by increasing the runtime PM usage count
(pm_runtime_get_noresume()).

Please remove this change from patch.

>         return 0;
>  }
>
> --
> 2.7.0
>

Kind regards
Uffe

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:

> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
an awful lot more changes like this, this shouldn't be an OMAP thing -
do we need to fix the core API and then roll out the transition in a
different way?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:

> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
an awful lot more changes like this, this shouldn't be an OMAP thing -
do we need to fix the core API and then roll out the transition in a
different way?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/735c9e60/attachment.sig>

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Ulf, I'd like to merge this along with other related fixes via the
> > ARM SoC tree if no objections, please review and ack if this look OK
> > to you.
> 
> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> send this via my mmc tree.
> 
> I guess that's okay as well!?

Naturally yes, please go ahead thanks!

Regards,

Tony

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Ulf, I'd like to merge this along with other related fixes via the
> > ARM SoC tree if no objections, please review and ack if this look OK
> > to you.
> 
> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> send this via my mmc tree.
> 
> I guess that's okay as well!?

Naturally yes, please go ahead thanks!

Regards,

Tony

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [160211 03:52]:
> On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:
> 
> > Mark, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> an awful lot more changes like this, this shouldn't be an OMAP thing -
> do we need to fix the core API and then roll out the transition in a
> different way?

Please feel free to pick up this one if you have other fixes
lined up, nothing stopping that.

There will be likely more fixes like this to make drivers follow
the PM runtime API documentation. These were just the initial
ones that were obvious.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie@kernel.org> [160211 03:52]:
> On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:
> 
> > Mark, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> an awful lot more changes like this, this shouldn't be an OMAP thing -
> do we need to fix the core API and then roll out the transition in a
> different way?

Please feel free to pick up this one if you have other fixes
lined up, nothing stopping that.

There will be likely more fixes like this to make drivers follow
the PM runtime API documentation. These were just the initial
ones that were obvious.

Regards,

Tony

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 16:02, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [160211 02:19]:
>> On 11 February 2016 at 00:02, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>> >
>> > Ulf, I'd like to merge this along with other related fixes via the
>> > ARM SoC tree if no objections, please review and ack if this look OK
>> > to you.
>>
>> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> send this via my mmc tree.
>>
>> I guess that's okay as well!?
>
> Naturally yes, please go ahead thanks!

Okay!

BTW, did you notice my other comments to the patch?

I can fix them before applying, unless you want to send a v2?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 16:02, Tony Lindgren <tony@atomide.com> wrote:
> * Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
>> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
>> >
>> > Ulf, I'd like to merge this along with other related fixes via the
>> > ARM SoC tree if no objections, please review and ack if this look OK
>> > to you.
>>
>> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> send this via my mmc tree.
>>
>> I guess that's okay as well!?
>
> Naturally yes, please go ahead thanks!

Okay!

BTW, did you notice my other comments to the patch?

I can fix them before applying, unless you want to send a v2?

Kind regards
Uffe

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@kernel.org> [160211 03:52]:

> > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > do we need to fix the core API and then roll out the transition in a
> > different way?

> Please feel free to pick up this one if you have other fixes
> lined up, nothing stopping that.

I'll take it myself unless there is a strong reason to merge it as part
of another series.

> There will be likely more fixes like this to make drivers follow
> the PM runtime API documentation. These were just the initial
> ones that were obvious.

This does sound like there's been a change in the interface compared to
what users are actually doing - is this an actual problem or is it just
a divergence from docs?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@kernel.org> [160211 03:52]:

> > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > do we need to fix the core API and then roll out the transition in a
> > different way?

> Please feel free to pick up this one if you have other fixes
> lined up, nothing stopping that.

I'll take it myself unless there is a strong reason to merge it as part
of another series.

> There will be likely more fixes like this to make drivers follow
> the PM runtime API documentation. These were just the initial
> ones that were obvious.

This does sound like there's been a change in the interface compared to
what users are actually doing - is this an actual problem or is it just
a divergence from docs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/290ead7c/attachment-0001.sig>

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160211 07:14]:
> On 11 February 2016 at 16:02, Tony Lindgren <tony@atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
> >> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> >> >
> >> > Ulf, I'd like to merge this along with other related fixes via the
> >> > ARM SoC tree if no objections, please review and ack if this look OK
> >> > to you.
> >>
> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> >> send this via my mmc tree.
> >>
> >> I guess that's okay as well!?
> >
> > Naturally yes, please go ahead thanks!
> 
> Okay!
> 
> BTW, did you notice my other comments to the patch?
> 
> I can fix them before applying, unless you want to send a v2?

Oh sorry, no I missed the rest of your comments again, I really
need to recalibrate my reading habits obviously if I keep
missing comments on regular basis..

You comments make sense to me. Below is the patch with only
minimal changes. Seems to work just fine and hit off mode for
suspend too.

Regards,

Tony

8< -------------------
>From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 9 Feb 2016 09:31:10 -0800
Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
 pm_runtime_reinit

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160211 07:14]:
> On 11 February 2016 at 16:02, Tony Lindgren <tony@atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
> >> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> >> >
> >> > Ulf, I'd like to merge this along with other related fixes via the
> >> > ARM SoC tree if no objections, please review and ack if this look OK
> >> > to you.
> >>
> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> >> send this via my mmc tree.
> >>
> >> I guess that's okay as well!?
> >
> > Naturally yes, please go ahead thanks!
> 
> Okay!
> 
> BTW, did you notice my other comments to the patch?
> 
> I can fix them before applying, unless you want to send a v2?

Oh sorry, no I missed the rest of your comments again, I really
need to recalibrate my reading habits obviously if I keep
missing comments on regular basis..

You comments make sense to me. Below is the patch with only
minimal changes. Seems to work just fine and hit off mode for
suspend too.

Regards,

Tony

8< -------------------
>From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 9 Feb 2016 09:31:10 -0800
Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
 pm_runtime_reinit

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc at vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);

Re: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]


> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Well, since most patches seem to be picked up individually now, I'd
prefer to do the same. This is v4.5 material, or?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Wolfram Sang]

> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Well, since most patches seem to be picked up individually now, I'd
prefer to do the same. This is v4.5 material, or?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/1252e49f/attachment.sig>

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [160211 07:54]:
> On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [160211 03:52]:
> 
> > > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > > do we need to fix the core API and then roll out the transition in a
> > > different way?
> 
> > Please feel free to pick up this one if you have other fixes
> > lined up, nothing stopping that.
> 
> I'll take it myself unless there is a strong reason to merge it as part
> of another series.

OK thanks!

> > There will be likely more fixes like this to make drivers follow
> > the PM runtime API documentation. These were just the initial
> > ones that were obvious.
> 
> This does sound like there's been a change in the interface compared to
> what users are actually doing - is this an actual problem or is it just
> a divergence from docs?

It's an actual problem at least on omaps as the omap_device code
is very picky about the hardware state.

Depending how the PM runtime is implemented, it may be a problem
for some other cases too.

For non-omap cases, my guess is that it's mostly a divergence from
the docs and non-critical.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie@kernel.org> [160211 07:54]:
> On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie@kernel.org> [160211 03:52]:
> 
> > > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > > do we need to fix the core API and then roll out the transition in a
> > > different way?
> 
> > Please feel free to pick up this one if you have other fixes
> > lined up, nothing stopping that.
> 
> I'll take it myself unless there is a strong reason to merge it as part
> of another series.

OK thanks!

> > There will be likely more fixes like this to make drivers follow
> > the PM runtime API documentation. These were just the initial
> > ones that were obvious.
> 
> This does sound like there's been a change in the interface compared to
> what users are actually doing - is this an actual problem or is it just
> a divergence from docs?

It's an actual problem at least on omaps as the omap_device code
is very picky about the hardware state.

Depending how the PM runtime is implemented, it may be a problem
for some other cases too.

For non-omap cases, my guess is that it's mostly a divergence from
the docs and non-critical.

Regards,

Tony

Re: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [160211 09:35]:
> 
> > Wolfram, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Well, since most patches seem to be picked up individually now, I'd
> prefer to do the same. This is v4.5 material, or?

Sure please do, thanks. And yes for v4.5 please. Although
I've only seen this happen with the MMC driver so far, there's
still a slight chance of this happening with the other drivers
using omap_device.

Regards,

Tony

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [160211 09:35]:
> 
> > Wolfram, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Well, since most patches seem to be picked up individually now, I'd
> prefer to do the same. This is v4.5 material, or?

Sure please do, thanks. And yes for v4.5 please. Although
I've only seen this happen with the MMC driver so far, there's
still a slight chance of this happening with the other drivers
using omap_device.

Regards,

Tony

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@kernel.org> [160211 07:54]:

> > This does sound like there's been a change in the interface compared to
> > what users are actually doing - is this an actual problem or is it just
> > a divergence from docs?

> It's an actual problem at least on omaps as the omap_device code
> is very picky about the hardware state.

> Depending how the PM runtime is implemented, it may be a problem
> for some other cases too.

Or people just aren't testing mainline that well (if this is broken in
v4.5 that suggests nobody noticed in -next) - do you know when this
broke?  It really seems like we may need to spin round on how this is
deployed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Mark Brown]

On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@kernel.org> [160211 07:54]:

> > This does sound like there's been a change in the interface compared to
> > what users are actually doing - is this an actual problem or is it just
> > a divergence from docs?

> It's an actual problem at least on omaps as the omap_device code
> is very picky about the hardware state.

> Depending how the PM runtime is implemented, it may be a problem
> for some other cases too.

Or people just aren't testing mainline that well (if this is broken in
v4.5 that suggests nobody noticed in -next) - do you know when this
broke?  It really seems like we may need to spin round on how this is
deployed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/f1717419/attachment.sig>

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie@kernel.org> [160211 10:38]:
> On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie@kernel.org> [160211 07:54]:
> 
> > > This does sound like there's been a change in the interface compared to
> > > what users are actually doing - is this an actual problem or is it just
> > > a divergence from docs?
> 
> > It's an actual problem at least on omaps as the omap_device code
> > is very picky about the hardware state.
> 
> > Depending how the PM runtime is implemented, it may be a problem
> > for some other cases too.
> 
> Or people just aren't testing mainline that well (if this is broken in
> v4.5 that suggests nobody noticed in -next) - do you know when this
> broke?  It really seems like we may need to spin round on how this is
> deployed.

I noticed it only with v4.5-rc1 and bisected it to commit 5de85b9d57ab
("PM / runtime: Re-init runtime PM states at probe error and driver
unbind") as it broke my PM tests for n900. For Linux next probably
was also broken for before that for some time.

Unfortunately based on the regressions I'm chasing every merge window
I'm suspecting that very few people are actually testing PM runtime
with mainline Linux kernel. Or they don't have the PM runtime fully
implemented in the mainline kernel for their devices. This is at
least for the SoC PM use case.

Ulf is working on a generic PM runtime test driver :) I'm hoping we
can then use that for basic regression testing on in an arch
independent way.

Regards,

Tony

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Mark Brown <broonie@kernel.org> [160211 10:38]:
> On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie@kernel.org> [160211 07:54]:
> 
> > > This does sound like there's been a change in the interface compared to
> > > what users are actually doing - is this an actual problem or is it just
> > > a divergence from docs?
> 
> > It's an actual problem at least on omaps as the omap_device code
> > is very picky about the hardware state.
> 
> > Depending how the PM runtime is implemented, it may be a problem
> > for some other cases too.
> 
> Or people just aren't testing mainline that well (if this is broken in
> v4.5 that suggests nobody noticed in -next) - do you know when this
> broke?  It really seems like we may need to spin round on how this is
> deployed.

I noticed it only with v4.5-rc1 and bisected it to commit 5de85b9d57ab
("PM / runtime: Re-init runtime PM states at probe error and driver
unbind") as it broke my PM tests for n900. For Linux next probably
was also broken for before that for some time.

Unfortunately based on the regressions I'm chasing every merge window
I'm suspecting that very few people are actually testing PM runtime
with mainline Linux kernel. Or they don't have the PM runtime fully
implemented in the mainline kernel for their devices. This is at
least for the SoC PM use case.

Ulf is working on a generic PM runtime test driver :) I'm hoping we
can then use that for basic regression testing on in an arch
independent way.

Regards,

Tony

Re: [PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

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

> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>  	int ret;
>  
>  	ret = omap_device_enable(pdev);
> -	if (ret)
> +	if (ret) {
> +		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>  		return ret;
> +	}
>  
>  	return pm_generic_runtime_resume(dev);
>  }

[PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

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

> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>  	int ret;
>  
>  	ret = omap_device_enable(pdev);
> -	if (ret)
> +	if (ret) {
> +		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>  		return ret;
> +	}
>  
>  	return pm_generic_runtime_resume(dev);
>  }

Re: [PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

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

> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct omap_device *od;
> +	int err;
>  
>  	switch (event) {
>  	case BUS_NOTIFY_DEL_DEVICE:
>  		if (pdev->archdata.od)
>  			omap_device_delete(pdev->archdata.od);
>  		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		od = to_omap_device(pdev);
> +		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +			dev_info(dev, "enabled after unload, idling\n");
> +			err = omap_device_idle(pdev);
> +			if (err)
> +				dev_err(dev, "failed to idle\n");
> +		}
> +		break;
>  	case BUS_NOTIFY_ADD_DEVICE:
>  		if (pdev->dev.of_node)
>  			omap_device_build_from_dt(pdev);

[PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

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

> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct omap_device *od;
> +	int err;
>  
>  	switch (event) {
>  	case BUS_NOTIFY_DEL_DEVICE:
>  		if (pdev->archdata.od)
>  			omap_device_delete(pdev->archdata.od);
>  		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		od = to_omap_device(pdev);
> +		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +			dev_info(dev, "enabled after unload, idling\n");
> +			err = omap_device_idle(pdev);
> +			if (err)
> +				dev_err(dev, "failed to idle\n");
> +		}
> +		break;
>  	case BUS_NOTIFY_ADD_DEVICE:
>  		if (pdev->dev.of_node)
>  			omap_device_build_from_dt(pdev);

Re: [PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Greg Kroah-Hartman]

On Wed, Feb 10, 2016 at 03:02:47PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Greg Kroah-Hartman]

On Wed, Feb 10, 2016 at 03:02:47PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>
>  drivers/i2c/busses/i2c-omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 08d26ba..13c4529 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
>
>  err_unuse_clocks:
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> -       pm_runtime_put(omap->dev);
> +       pm_runtime_dont_use_autosuspend(omap->dev);
> +       pm_runtime_put_sync(omap->dev);
>         pm_runtime_disable(&pdev->dev);
>  err_free_mem:
>
> @@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
>                 return ret;
>
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return 0;
> --
> 2.7.0
>

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>
>  drivers/i2c/busses/i2c-omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 08d26ba..13c4529 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
>
>  err_unuse_clocks:
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> -       pm_runtime_put(omap->dev);
> +       pm_runtime_dont_use_autosuspend(omap->dev);
> +       pm_runtime_put_sync(omap->dev);
>         pm_runtime_disable(&pdev->dev);
>  err_free_mem:
>
> @@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
>                 return ret;
>
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return 0;
> --
> 2.7.0
>

Re: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-spi@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>  drivers/spi/spi-omap2-mcspi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 7273820..0caa3c8 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
>         return status;
>
>  disable_pm:
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>  free_master:
>         spi_master_put(master);
> @@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
>         struct spi_master *master = platform_get_drvdata(pdev);
>         struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
>
> +       pm_runtime_dont_use_autosuspend(mcspi->dev);
>         pm_runtime_put_sync(mcspi->dev);
>         pm_runtime_disable(&pdev->dev);
>
> --
> 2.7.0
>

[PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-spi at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>  drivers/spi/spi-omap2-mcspi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 7273820..0caa3c8 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
>         return status;
>
>  disable_pm:
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>  free_master:
>         spi_master_put(master);
> @@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
>         struct spi_master *master = platform_get_drvdata(pdev);
>         struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
>
> +       pm_runtime_dont_use_autosuspend(mcspi->dev);
>         pm_runtime_put_sync(mcspi->dev);
>         pm_runtime_disable(&pdev->dev);
>
> --
> 2.7.0
>

Re: [PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
> ---
>  drivers/tty/serial/8250/8250_omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index a2c0734..81ff337 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
>         pm_runtime_put_autosuspend(&pdev->dev);
>         return 0;
>  err:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return ret;
>  }
> @@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
>  {
>         struct omap8250_priv *priv = platform_get_drvdata(pdev);
>
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         serial8250_unregister_port(priv->line);
> --
> 2.7.0
>

[PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
> ---
>  drivers/tty/serial/8250/8250_omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index a2c0734..81ff337 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
>         pm_runtime_put_autosuspend(&pdev->dev);
>         return 0;
>  err:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return ret;
>  }
> @@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
>  {
>         struct omap8250_priv *priv = platform_get_drvdata(pdev);
>
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         serial8250_unregister_port(priv->line);
> --
> 2.7.0
>

Re: [PATCH 5/7] serial: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe


> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if
> this look OK to you.
>
> ---
>  drivers/tty/serial/omap-serial.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index b645f92..5c43f75 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>         return 0;
>
>  err_add_port:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         pm_qos_remove_request(&up->pm_qos_request);
>         device_init_wakeup(up->dev, false);
> @@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
>  {
>         struct uart_omap_port *up = platform_get_drvdata(dev);
>
> +       pm_runtime_dont_use_autosuspend(up->dev);
>         pm_runtime_put_sync(up->dev);
>         pm_runtime_disable(up->dev);
>         uart_remove_one_port(&serial_omap_reg, &up->port);
> --
> 2.7.0
>

[PATCH 5/7] serial: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe


> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if
> this look OK to you.
>
> ---
>  drivers/tty/serial/omap-serial.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index b645f92..5c43f75 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>         return 0;
>
>  err_add_port:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         pm_qos_remove_request(&up->pm_qos_request);
>         device_init_wakeup(up->dev, false);
> @@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
>  {
>         struct uart_omap_port *up = platform_get_drvdata(dev);
>
> +       pm_runtime_dont_use_autosuspend(up->dev);
>         pm_runtime_put_sync(up->dev);
>         pm_runtime_disable(up->dev);
>         uart_remove_one_port(&serial_omap_reg, &up->port);
> --
> 2.7.0
>

Re: [PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
> Cc: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> Cc: Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>         int ret;
>
>         ret = omap_device_enable(pdev);
> -       if (ret)
> +       if (ret) {
> +               dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>                 return ret;
> +       }
>
>         return pm_generic_runtime_resume(dev);
>  }
> --
> 2.7.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>         int ret;
>
>         ret = omap_device_enable(pdev);
> -       if (ret)
> +       if (ret) {
> +               dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>                 return ret;
> +       }
>
>         return pm_generic_runtime_resume(dev);
>  }
> --
> 2.7.0
>

Re: [PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>         struct platform_device *pdev = to_platform_device(dev);
>         struct omap_device *od;
> +       int err;
>
>         switch (event) {
>         case BUS_NOTIFY_DEL_DEVICE:
>                 if (pdev->archdata.od)
>                         omap_device_delete(pdev->archdata.od);
>                 break;
> +       case BUS_NOTIFY_UNBOUND_DRIVER:
> +               od = to_omap_device(pdev);
> +               if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +                       dev_info(dev, "enabled after unload, idling\n");
> +                       err = omap_device_idle(pdev);
> +                       if (err)
> +                               dev_err(dev, "failed to idle\n");
> +               }
> +               break;
>         case BUS_NOTIFY_ADD_DEVICE:
>                 if (pdev->dev.of_node)
>                         omap_device_build_from_dt(pdev);
> --
> 2.7.0
>

[PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

[Ulf Hansson]

On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>         struct platform_device *pdev = to_platform_device(dev);
>         struct omap_device *od;
> +       int err;
>
>         switch (event) {
>         case BUS_NOTIFY_DEL_DEVICE:
>                 if (pdev->archdata.od)
>                         omap_device_delete(pdev->archdata.od);
>                 break;
> +       case BUS_NOTIFY_UNBOUND_DRIVER:
> +               od = to_omap_device(pdev);
> +               if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +                       dev_info(dev, "enabled after unload, idling\n");
> +                       err = omap_device_idle(pdev);
> +                       if (err)
> +                               dev_err(dev, "failed to idle\n");
> +               }
> +               break;
>         case BUS_NOTIFY_ADD_DEVICE:
>                 if (pdev->dev.of_node)
>                         omap_device_build_from_dt(pdev);
> --
> 2.7.0
>

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 18:26, Tony Lindgren <tony@atomide.com> wrote:
> * Ulf Hansson <ulf.hansson@linaro.org> [160211 07:14]:
>> On 11 February 2016 at 16:02, Tony Lindgren <tony@atomide.com> wrote:
>> > * Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
>> >> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
>> >> >
>> >> > Ulf, I'd like to merge this along with other related fixes via the
>> >> > ARM SoC tree if no objections, please review and ack if this look OK
>> >> > to you.
>> >>
>> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> >> send this via my mmc tree.
>> >>
>> >> I guess that's okay as well!?
>> >
>> > Naturally yes, please go ahead thanks!
>>
>> Okay!
>>
>> BTW, did you notice my other comments to the patch?
>>
>> I can fix them before applying, unless you want to send a v2?
>
> Oh sorry, no I missed the rest of your comments again, I really
> need to recalibrate my reading habits obviously if I keep
> missing comments on regular basis..
>
> You comments make sense to me. Below is the patch with only
> minimal changes. Seems to work just fine and hit off mode for
> suspend too.
>
> Regards,
>
> Tony
>
> 8< -------------------
> From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 9 Feb 2016 09:31:10 -0800
> Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
>  pm_runtime_reinit
>
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);

Thanks, applied for fixes!

Kind regards
Uffe

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Ulf Hansson]

On 11 February 2016 at 18:26, Tony Lindgren <tony@atomide.com> wrote:
> * Ulf Hansson <ulf.hansson@linaro.org> [160211 07:14]:
>> On 11 February 2016 at 16:02, Tony Lindgren <tony@atomide.com> wrote:
>> > * Ulf Hansson <ulf.hansson@linaro.org> [160211 02:19]:
>> >> On 11 February 2016 at 00:02, Tony Lindgren <tony@atomide.com> wrote:
>> >> >
>> >> > Ulf, I'd like to merge this along with other related fixes via the
>> >> > ARM SoC tree if no objections, please review and ack if this look OK
>> >> > to you.
>> >>
>> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> >> send this via my mmc tree.
>> >>
>> >> I guess that's okay as well!?
>> >
>> > Naturally yes, please go ahead thanks!
>>
>> Okay!
>>
>> BTW, did you notice my other comments to the patch?
>>
>> I can fix them before applying, unless you want to send a v2?
>
> Oh sorry, no I missed the rest of your comments again, I really
> need to recalibrate my reading habits obviously if I keep
> missing comments on regular basis..
>
> You comments make sense to me. Below is the patch with only
> minimal changes. Seems to work just fine and hit off mode for
> suspend too.
>
> Regards,
>
> Tony
>
> 8< -------------------
> From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 9 Feb 2016 09:31:10 -0800
> Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
>  pm_runtime_reinit
>
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);

Thanks, applied for fixes!

Kind regards
Uffe

Re: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Wed, Feb 10, 2016 at 03:02:45PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c@vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Applied to for-current, thanks!


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

[Wolfram Sang]

On Wed, Feb 10, 2016 at 03:02:45PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c at vger.kernel.org
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Applied to for-current, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/d994bb7d/attachment.sig>

Re: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160212 05:00]:
> On 11 February 2016 at 18:26, Tony Lindgren <tony@atomide.com> wrote:
> > Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
> >  pm_runtime_reinit
>
> Thanks, applied for fixes!

Ulf, any news on getting this into the mainline tree?

My PM tests have been now broken for six weeks or something
because of this!

Regards,

Tony

[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson@linaro.org> [160212 05:00]:
> On 11 February 2016 at 18:26, Tony Lindgren <tony@atomide.com> wrote:
> > Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
> >  pm_runtime_reinit
>
> Thanks, applied for fixes!

Ulf, any news on getting this into the mainline tree?

My PM tests have been now broken for six weeks or something
because of this!

Regards,

Tony