| Message ID | 1378913560-2752-9-git-send-email-mika.westerberg@linux.intel.com |
|---|---|
| State | Superseded |
| Headers | show |
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.
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
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.
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
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...
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
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
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
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); }
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(-)