Patchwork [v2,8/9] spi: prepare runtime PM support for SPI devices

login
register
mail settings
Submitter Mika Westerberg
Date Sept. 11, 2013, 3:32 p.m.
Message ID <1378913560-2752-9-git-send-email-mika.westerberg@linux.intel.com>
Download mbox | patch
Permalink /patch/274325/
State Superseded
Headers show

Comments

Mika Westerberg - Sept. 11, 2013, 3:32 p.m.
This patch adds runtime PM support for the SPI bus analogous to what has
been done for the I2C bus. This means that the SPI core prepares runtime PM
for a client device just before a driver is about to be bound to it.
Devices that are not bound to any driver are not prepared for runtime PM.

In order to participate the runtime PM of the SPI bus a device driver needs
to drop the device runtime PM reference count by calling pm_runtime_put()
in its ->probe() callback and possibly implement rest of the runtime PM
callbacks.

If the driver doesn't support runtime PM, the device in question is
regarded as being runtime PM active and powered on.

This patch adds also runtime PM support for the SPI master device because
it is needed to be able to runtime power manage the SPI controller device.
The SPI master device is handled along with the SPI controller device.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)
Mark Brown - Sept. 11, 2013, 3:51 p.m.
On Wed, Sep 11, 2013 at 06:32:39PM +0300, Mika Westerberg wrote:
> This patch adds runtime PM support for the SPI bus analogous to what has
> been done for the I2C bus. This means that the SPI core prepares runtime PM
> for a client device just before a driver is about to be bound to it.
> Devices that are not bound to any driver are not prepared for runtime PM.

Acked-by: Mark Brown <broonie@linaro.org>

I would be able to have this and the other patch in the SPI tree in case
it overlaps with other work - I'm not sure what the plan will be for
merging this stuff but if there were a branch which I could merge into
the SPI tree that'd be good.
Mika Westerberg - Sept. 12, 2013, 9:27 a.m.
On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> On Wed, Sep 11, 2013 at 06:32:39PM +0300, Mika Westerberg wrote:
> > This patch adds runtime PM support for the SPI bus analogous to what has
> > been done for the I2C bus. This means that the SPI core prepares runtime PM
> > for a client device just before a driver is about to be bound to it.
> > Devices that are not bound to any driver are not prepared for runtime PM.
> 
> Acked-by: Mark Brown <broonie@linaro.org>

Thanks!

> I would be able to have this and the other patch in the SPI tree in case
> it overlaps with other work - I'm not sure what the plan will be for
> merging this stuff but if there were a branch which I could merge into
> the SPI tree that'd be good.

I think these two can go via your SPI tree as they shouldn't have
dependencies to the I2C tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown - Sept. 12, 2013, 9:31 a.m.
On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:

> > I would be able to have this and the other patch in the SPI tree in case
> > it overlaps with other work - I'm not sure what the plan will be for
> > merging this stuff but if there were a branch which I could merge into
> > the SPI tree that'd be good.

> I think these two can go via your SPI tree as they shouldn't have
> dependencies to the I2C tree.

There's all the driver changes though - it seems best to push the whole
series through one branch so there's fewer bisection problems.
Mika Westerberg - Sept. 12, 2013, 9:43 a.m.
On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
> On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> 
> > > I would be able to have this and the other patch in the SPI tree in case
> > > it overlaps with other work - I'm not sure what the plan will be for
> > > merging this stuff but if there were a branch which I could merge into
> > > the SPI tree that'd be good.
> 
> > I think these two can go via your SPI tree as they shouldn't have
> > dependencies to the I2C tree.
> 
> There's all the driver changes though - it seems best to push the whole
> series through one branch so there's fewer bisection problems.

Ah, right. Then I suppose the right tree would be the I2C tree (as majority
of the patches are I2C related)?

Wolfram, are you OK with this?
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang - Sept. 12, 2013, 11:04 a.m.
On Thu, Sep 12, 2013 at 01:04:55PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote:
> > On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
> > > On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> > > > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> > > 
> > > > > I would be able to have this and the other patch in the SPI tree in case
> > > > > it overlaps with other work - I'm not sure what the plan will be for
> > > > > merging this stuff but if there were a branch which I could merge into
> > > > > the SPI tree that'd be good.
> > > 
> > > > I think these two can go via your SPI tree as they shouldn't have
> > > > dependencies to the I2C tree.
> > > 
> > > There's all the driver changes though - it seems best to push the whole
> > > series through one branch so there's fewer bisection problems.
> > 
> > Ah, right. Then I suppose the right tree would be the I2C tree (as majority
> > of the patches are I2C related)?
> > 
> > Wolfram, are you OK with this?
> 
> Alternatively, I can apply them too if everyone is OK with that.
> 
> They are PM+ACPI changes after all ...

I'd like to give at least an ACK. But I need to find some time for that.
Is it urgent? Looks like 3.13 material to me...
Rafael J. Wysocki - Sept. 12, 2013, 11:04 a.m.
On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote:
> On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
> > On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> > > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> > 
> > > > I would be able to have this and the other patch in the SPI tree in case
> > > > it overlaps with other work - I'm not sure what the plan will be for
> > > > merging this stuff but if there were a branch which I could merge into
> > > > the SPI tree that'd be good.
> > 
> > > I think these two can go via your SPI tree as they shouldn't have
> > > dependencies to the I2C tree.
> > 
> > There's all the driver changes though - it seems best to push the whole
> > series through one branch so there's fewer bisection problems.
> 
> Ah, right. Then I suppose the right tree would be the I2C tree (as majority
> of the patches are I2C related)?
> 
> Wolfram, are you OK with this?

Alternatively, I can apply them too if everyone is OK with that.

They are PM+ACPI changes after all ...

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mika Westerberg - Sept. 12, 2013, 12:20 p.m.
On Thu, Sep 12, 2013 at 01:04:28PM +0200, Wolfram Sang wrote:
> On Thu, Sep 12, 2013 at 01:04:55PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote:
> > > On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
> > > > On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> > > > > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> > > > 
> > > > > > I would be able to have this and the other patch in the SPI tree in case
> > > > > > it overlaps with other work - I'm not sure what the plan will be for
> > > > > > merging this stuff but if there were a branch which I could merge into
> > > > > > the SPI tree that'd be good.
> > > > 
> > > > > I think these two can go via your SPI tree as they shouldn't have
> > > > > dependencies to the I2C tree.
> > > > 
> > > > There's all the driver changes though - it seems best to push the whole
> > > > series through one branch so there's fewer bisection problems.
> > > 
> > > Ah, right. Then I suppose the right tree would be the I2C tree (as majority
> > > of the patches are I2C related)?
> > > 
> > > Wolfram, are you OK with this?
> > 
> > Alternatively, I can apply them too if everyone is OK with that.
> > 
> > They are PM+ACPI changes after all ...
> 
> I'd like to give at least an ACK. But I need to find some time for that.
> Is it urgent? Looks like 3.13 material to me...

It's not urgent. Please take your time.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mika Westerberg - Sept. 12, 2013, 12:25 p.m.
On Thu, Sep 12, 2013 at 01:04:55PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote:
> > On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
> > > On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
> > > > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
> > > 
> > > > > I would be able to have this and the other patch in the SPI tree in case
> > > > > it overlaps with other work - I'm not sure what the plan will be for
> > > > > merging this stuff but if there were a branch which I could merge into
> > > > > the SPI tree that'd be good.
> > > 
> > > > I think these two can go via your SPI tree as they shouldn't have
> > > > dependencies to the I2C tree.
> > > 
> > > There's all the driver changes though - it seems best to push the whole
> > > series through one branch so there's fewer bisection problems.
> > 
> > Ah, right. Then I suppose the right tree would be the I2C tree (as majority
> > of the patches are I2C related)?
> > 
> > Wolfram, are you OK with this?
> 
> Alternatively, I can apply them too if everyone is OK with that.

Sounds good to me, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 978dda2..94ebab9 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -240,22 +240,61 @@  EXPORT_SYMBOL_GPL(spi_bus_type);
 static int spi_drv_probe(struct device *dev)
 {
 	const struct spi_driver		*sdrv = to_spi_driver(dev->driver);
+	struct spi_device		*spi = to_spi_device(dev);
+	int				ret;
 
-	return sdrv->probe(to_spi_device(dev));
+	/* Make sure that the master is powered on */
+	pm_runtime_get_sync(&spi->master->dev);
+
+	/*
+	 * Enable runtime PM for the SPI device. The SPI device driver can
+	 * participate in runtime PM by calling pm_runtime_put() in its
+	 * probe() callback.
+	 */
+	pm_runtime_get_noresume(&spi->dev);
+	pm_runtime_set_active(&spi->dev);
+	pm_runtime_enable(&spi->dev);
+
+	ret = sdrv->probe(spi);
+	if (ret) {
+		pm_runtime_disable(&spi->dev);
+		pm_runtime_set_suspended(&spi->dev);
+		pm_runtime_put_noidle(&spi->dev);
+	}
+
+	pm_runtime_put(&spi->master->dev);
+
+	return ret;
 }
 
 static int spi_drv_remove(struct device *dev)
 {
 	const struct spi_driver		*sdrv = to_spi_driver(dev->driver);
+	struct spi_device		*spi = to_spi_device(dev);
+	int				ret;
+
+	pm_runtime_get_sync(&spi->master->dev);
+
+	ret = sdrv->remove(spi);
+
+	/* Undo the runtime PM done in spi_drv_probe() */
+	pm_runtime_disable(&spi->dev);
+	pm_runtime_set_suspended(&spi->dev);
+	pm_runtime_put_noidle(&spi->dev);
 
-	return sdrv->remove(to_spi_device(dev));
+	pm_runtime_put(&spi->master->dev);
+
+	return ret;
 }
 
 static void spi_drv_shutdown(struct device *dev)
 {
 	const struct spi_driver		*sdrv = to_spi_driver(dev->driver);
+	struct spi_device		*spi = to_spi_device(dev);
 
+	pm_runtime_get_sync(&spi->master->dev);
 	sdrv->shutdown(to_spi_device(dev));
+	pm_runtime_put(&spi->master->dev);
 }
 
 /**
@@ -1174,6 +1213,10 @@  int spi_register_master(struct spi_master *master)
 		}
 	}
 
+	pm_runtime_set_active(&master->dev);
+	pm_runtime_no_callbacks(&master->dev);
+	pm_runtime_enable(&master->dev);
+
 	mutex_lock(&board_lock);
 	list_add_tail(&master->list, &spi_master_list);
 	list_for_each_entry(bi, &board_list, list)
@@ -1217,6 +1260,8 @@  void spi_unregister_master(struct spi_master *master)
 	list_del(&master->list);
 	mutex_unlock(&board_lock);
 
+	pm_runtime_disable(&master->dev);
+
 	dummy = device_for_each_child(&master->dev, NULL, __unregister);
 	device_unregister(&master->dev);
 }