* [PATCH] i2c: Hook up runtime PM support
@ 2010-02-03 13:22 Mark Brown
[not found] ` <1265203367-21344-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2010-02-03 13:22 UTC (permalink / raw)
To: Jean Delvare
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Rafael J. Wysocki, Mark Brown
Allow I2C drivers to make use of the runtime PM framework by adding
bus implementations of the runtime PM operations. These simply
immediately suspend when the device is idle. The runtime PM framework
provides drivers with off the shelf refcounts for enables and sysfs
control for managing runtime suspend from userspace so is useful even
without meaningful input from the bus.
Signed-off-by: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
---
drivers/i2c/i2c-core.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 10be7b5..985eaac 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -34,6 +34,7 @@
#include <linux/hardirq.h>
#include <linux/irqflags.h>
#include <linux/rwsem.h>
+#include <linux/pm_runtime.h>
#include <asm/uaccess.h>
#include "i2c-core.h"
@@ -184,6 +185,43 @@ static int i2c_device_pm_resume(struct device *dev)
#define i2c_device_pm_resume NULL
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int i2c_device_runtime_suspend(struct device *dev)
+{
+ const struct dev_pm_ops *pm;
+
+ if (!dev->driver)
+ return 0;
+ pm = dev->driver->pm;
+ if (!pm || !pm->runtime_suspend)
+ return 0;
+ return pm->runtime_suspend(dev);
+}
+
+static int i2c_device_runtime_resume(struct device *dev)
+{
+ const struct dev_pm_ops *pm;
+
+ if (!dev->driver)
+ return 0;
+ pm = dev->driver->pm;
+ if (!pm || !pm->runtime_resume)
+ return 0;
+ return pm->runtime_resume(dev);
+}
+
+static int i2c_device_runtime_idle(struct device *dev)
+{
+ /* I2C devices are very independent of each other so we
+ * suspend them immediately. */
+ return pm_runtime_suspend(dev);
+}
+#else
+#define i2c_device_runtime_suspend NULL
+#define i2c_device_runtime_resume NULL
+#define i2c_device_runtime_idle NULL
+#endif
+
static int i2c_device_suspend(struct device *dev, pm_message_t mesg)
{
struct i2c_client *client = i2c_verify_client(dev);
@@ -251,6 +289,9 @@ static const struct attribute_group *i2c_dev_attr_groups[] = {
static const struct dev_pm_ops i2c_device_pm_ops = {
.suspend = i2c_device_pm_suspend,
.resume = i2c_device_pm_resume,
+ .runtime_suspend = i2c_device_runtime_suspend,
+ .runtime_resume = i2c_device_runtime_resume,
+ .runtime_idle = i2c_device_runtime_idle,
};
struct bus_type i2c_bus_type = {
--
1.6.6
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] i2c: Hook up runtime PM support
[not found] ` <1265203367-21344-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
@ 2010-02-04 21:57 ` Rafael J. Wysocki
[not found] ` <201002042257.27145.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Rafael J. Wysocki @ 2010-02-04 21:57 UTC (permalink / raw)
To: Mark Brown
Cc: Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA, pm list,
Alan Stern, Matthew Garrett
On Wednesday 03 February 2010, Mark Brown wrote:
> Allow I2C drivers to make use of the runtime PM framework by adding
> bus implementations of the runtime PM operations. These simply
> immediately suspend when the device is idle.
Perhaps it would be a good idea to give the driver a chance to veto
the suspend by calling its _idle callback? We do that for PCI and turns out to
be quite useful.
> The runtime PM framework provides drivers with off the shelf refcounts for
> enables and sysfs control for managing runtime suspend from userspace so is
> useful even without meaningful input from the bus.
>
> Signed-off-by: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> drivers/i2c/i2c-core.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 10be7b5..985eaac 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -34,6 +34,7 @@
> #include <linux/hardirq.h>
> #include <linux/irqflags.h>
> #include <linux/rwsem.h>
> +#include <linux/pm_runtime.h>
> #include <asm/uaccess.h>
>
> #include "i2c-core.h"
> @@ -184,6 +185,43 @@ static int i2c_device_pm_resume(struct device *dev)
> #define i2c_device_pm_resume NULL
> #endif
>
> +#ifdef CONFIG_PM_RUNTIME
> +static int i2c_device_runtime_suspend(struct device *dev)
> +{
> + const struct dev_pm_ops *pm;
> +
> + if (!dev->driver)
> + return 0;
> + pm = dev->driver->pm;
> + if (!pm || !pm->runtime_suspend)
> + return 0;
> + return pm->runtime_suspend(dev);
> +}
> +
> +static int i2c_device_runtime_resume(struct device *dev)
> +{
> + const struct dev_pm_ops *pm;
> +
> + if (!dev->driver)
> + return 0;
> + pm = dev->driver->pm;
> + if (!pm || !pm->runtime_resume)
> + return 0;
> + return pm->runtime_resume(dev);
> +}
> +
> +static int i2c_device_runtime_idle(struct device *dev)
> +{
> + /* I2C devices are very independent of each other so we
> + * suspend them immediately. */
> + return pm_runtime_suspend(dev);
> +}
> +#else
> +#define i2c_device_runtime_suspend NULL
> +#define i2c_device_runtime_resume NULL
> +#define i2c_device_runtime_idle NULL
> +#endif
> +
> static int i2c_device_suspend(struct device *dev, pm_message_t mesg)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> @@ -251,6 +289,9 @@ static const struct attribute_group *i2c_dev_attr_groups[] = {
> static const struct dev_pm_ops i2c_device_pm_ops = {
> .suspend = i2c_device_pm_suspend,
> .resume = i2c_device_pm_resume,
> + .runtime_suspend = i2c_device_runtime_suspend,
> + .runtime_resume = i2c_device_runtime_resume,
> + .runtime_idle = i2c_device_runtime_idle,
> };
>
> struct bus_type i2c_bus_type = {
>
Rafael
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-pm] [PATCH] i2c: Hook up runtime PM support
[not found] ` <201002042257.27145.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2010-02-05 10:39 ` Mark Brown
[not found] ` <20100205103915.GA2600-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2010-02-05 10:39 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Jean Delvare, pm list, linux-i2c-u79uwXL29TY76Z2rM5mHXA
On Thu, Feb 04, 2010 at 10:57:27PM +0100, Rafael J. Wysocki wrote:
> On Wednesday 03 February 2010, Mark Brown wrote:
> > Allow I2C drivers to make use of the runtime PM framework by adding
> > bus implementations of the runtime PM operations. These simply
> > immediately suspend when the device is idle.
> Perhaps it would be a good idea to give the driver a chance to veto
> the suspend by calling its _idle callback? We do that for PCI and turns out to
> be quite useful.
Hrm, I guess. It seems an odd thing to want to use - for a bus like I2C
there's nothing other than the driver involved so the request that is
being vetoed will have been initiated by the driver which seems wrong.
Out of interest do you have any pointers to drivers using this (my greps
aren't turning anything up in -next)?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-pm] [PATCH] i2c: Hook up runtime PM support
[not found] ` <20100205103915.GA2600-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
@ 2010-02-05 22:09 ` Rafael J. Wysocki
[not found] ` <201002052309.13966.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Rafael J. Wysocki @ 2010-02-05 22:09 UTC (permalink / raw)
To: Mark Brown; +Cc: Jean Delvare, pm list, linux-i2c-u79uwXL29TY76Z2rM5mHXA
On Friday 05 February 2010, you wrote:
> On Thu, Feb 04, 2010 at 10:57:27PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday 03 February 2010, Mark Brown wrote:
> > > Allow I2C drivers to make use of the runtime PM framework by adding
> > > bus implementations of the runtime PM operations. These simply
> > > immediately suspend when the device is idle.
>
> > Perhaps it would be a good idea to give the driver a chance to veto
> > the suspend by calling its _idle callback? We do that for PCI and turns out to
> > be quite useful.
>
> Hrm, I guess. It seems an odd thing to want to use - for a bus like I2C
> there's nothing other than the driver involved so the request that is
> being vetoed will have been initiated by the driver which seems wrong.
Not really. _idle is also called automatically by the runtime PM core after
_resume in case the device may be suspended again. Your _idle has to handle
this case as well and that's when the driver may want to veto the suspend.
> Out of interest do you have any pointers to drivers using this (my greps
> aren't turning anything up in -next)?
There aren't any in -next, because I'm waiting for the base PCI runtime PM
code to settle down. I have two in my private queue at the moment , for r8169
and e1000e (I posted some older versions of them some time ago, but they
wouldn't fit the current framework too well, which is the basic reason I'm
sitting on them, so that I don't have to post too many updates :-)).
I can send them to you privately, if needed.
Rafael
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-pm] [PATCH] i2c: Hook up runtime PM support
[not found] ` <201002052309.13966.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2010-02-05 23:17 ` Mark Brown
0 siblings, 0 replies; 5+ messages in thread
From: Mark Brown @ 2010-02-05 23:17 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Jean Delvare, pm list, linux-i2c-u79uwXL29TY76Z2rM5mHXA
On Fri, Feb 05, 2010 at 11:09:13PM +0100, Rafael J. Wysocki wrote:
> On Friday 05 February 2010, you wrote:
> > Hrm, I guess. It seems an odd thing to want to use - for a bus like I2C
> > there's nothing other than the driver involved so the request that is
> > being vetoed will have been initiated by the driver which seems wrong.
> Not really. _idle is also called automatically by the runtime PM core after
> _resume in case the device may be suspended again. Your _idle has to handle
> this case as well and that's when the driver may want to veto the suspend.
I was viewing that as being part of the same case, going on the basis
that the driver would have marked the device as active already if
something had changed over the suspend. The use cases that jumped out
at me for the veto were for buses or classes rather than for individual
devices.
> > Out of interest do you have any pointers to drivers using this (my greps
> > aren't turning anything up in -next)?
> There aren't any in -next, because I'm waiting for the base PCI runtime PM
> code to settle down. I have two in my private queue at the moment , for r8169
> and e1000e (I posted some older versions of them some time ago, but they
> wouldn't fit the current framework too well, which is the basic reason I'm
> sitting on them, so that I don't have to post too many updates :-)).
> I can send them to you privately, if needed.
No, that's OK - like I say, it was just out of interest.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-02-05 23:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-03 13:22 [PATCH] i2c: Hook up runtime PM support Mark Brown
[not found] ` <1265203367-21344-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2010-02-04 21:57 ` Rafael J. Wysocki
[not found] ` <201002042257.27145.rjw-KKrjLPT3xs0@public.gmane.org>
2010-02-05 10:39 ` [linux-pm] " Mark Brown
[not found] ` <20100205103915.GA2600-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2010-02-05 22:09 ` Rafael J. Wysocki
[not found] ` <201002052309.13966.rjw-KKrjLPT3xs0@public.gmane.org>
2010-02-05 23:17 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).