From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Magnus Damm <damm@igel.co.jp>, linux-pm@lists.linux-foundation.org
Subject: Re: runtime PM: common hooks for static and runtime PM
Date: Wed, 17 Mar 2010 15:32:30 -0700 [thread overview]
Message-ID: <874okepojl.fsf@deeprootsystems.com> (raw)
In-Reply-To: <201003172246.32443.rjw@sisk.pl> (Rafael J. Wysocki's message of "Wed\, 17 Mar 2010 22\:46\:32 +0100")
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Wednesday 17 March 2010, Alan Stern wrote:
>> On Wed, 17 Mar 2010, Kevin Hilman wrote:
>>
>> > >> In my case, the driver's runtime_suspend and runtime_resume hooks are
>> > >> not where the clocks are managed. The actual hardware enable/disable
>> > >> is done in the bus-level runtime PM hooks, in this case platform_bus.
>> > >> So having the system PM methods directly call the drivers runtime PM
>> > >> methods doesn't help. In fact, because we handle the hardware at the
>> > >> bus level, most drivers can live without any runtime PM methods, and
>> > >> simply use get/put.
>> > >>
>> > >> I've worked around this temporarily by calling the
>> > >> bus->pm->runtime_suspend() and ->runtime_resume() methods from the
>> > >> system PM methods, but am curious if that is an acceptable solution.
>> > >
>> > > If the platform bus manages the clocks from within its runtime-PM
>> > > routines, then it ought to provide a similar service from within its
>> > > system-PM routines.
>> >
>> > Hmm, good point. Currently the platform bus code allows overriding
>> > the runtime PM methods via weak functions (drivers/base/platform.c)
>> > but not the system PM methods. Below is a patch that allows platforms
>> > to extend the system PM methods of the platform bus as well.
>> >
>> > > You could do it by calling the bus's runtime-PM
>> > > routines indirectly through the method pointers (as you do now), or by
>> > > calling the runtime-PM routines directly, or by making the runtime-PM
>> > > routines and the system-PM routines both call a separate common
>> > > function responsible for managing the clocks.
>> >
>> > Using the patch below, I am able to add custom system PM hooks and then
>> > use common code to manage the clocks for runtime PM and system PM.
>> >
>> > Comments?
>> >
>> > Kevin
>> >
>> >
>> > commit ca2173923bae3ba631e12698401ef0b59ec0433c
>> > Author: Kevin Hilman <khilman@deeprootsystems.com>
>> > Date: Wed Mar 17 09:36:10 2010 -0700
>> >
>> > platform_bus: allow custom extensions to system PM methods
>> >
>> > When runtime PM for platform_bus was added, it allowed for platforms
>> > to customize the runtime PM methods since they are defined as weak
>> > symbols.
>> >
>> > This patch allows platforms to extend the system PM methods with
>> > custom hooks as well so runtime PM and system PM extensions can be
>> > managed together.
>> >
>> > Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> >
>> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> > index 1ba9d61..a30f850 100644
>> > --- a/drivers/base/platform.c
>> > +++ b/drivers/base/platform.c
>> > @@ -729,6 +729,26 @@ static void platform_pm_complete(struct device *dev)
>> >
>> > #ifdef CONFIG_SUSPEND
>>
>> This probably should be CONFIG_SLEEP.
>
> CONFIG_PM_SLEEP to be precise.
That #ifdef was not part of my patch, it was just part of the diff
context. I'm just adding these new hooks inside the same ifdef that
the platform_bus system PM hooks are defined.
Are you suggesting I also fixup the #ifdef in that code?
>> > +int __weak platform_pm_suspend_hook(struct device *dev)
>> > +{
>> > + return 0;
>> > +}
>> > +
>> > +int __weak platform_pm_suspend_noirq_hook(struct device *dev)
>> > +{
>> > + return 0;
>> > +}
>> > +
>> > +int __weak platform_pm_resume_hook(struct device *dev)
>> > +{
>> > + return 0;
>> > +}
>> > +
>> > +int __weak platform_pm_resume_noirq_hook(struct device *dev)
>> > +{
>> > + return 0;
>> > +}
>> > +
>> > static int platform_pm_suspend(struct device *dev)
>> > {
>> > struct device_driver *drv = dev->driver;
>> > @@ -744,6 +764,8 @@ static int platform_pm_suspend(struct device *dev)
>> > ret = platform_legacy_suspend(dev, PMSG_SUSPEND);
>> > }
>> >
>> > + platform_pm_suspend_hook(dev);
>> > +
>> > return ret;
>> > }
>> >
>> > @@ -760,6 +782,8 @@ static int platform_pm_suspend_noirq(struct device *dev)
>> > ret = drv->pm->suspend_noirq(dev);
>> > }
>> >
>> > + platform_pm_suspend_noirq_hook(dev);
>> > +
>> > return ret;
>> > }
>> >
>> > @@ -768,6 +792,8 @@ static int platform_pm_resume(struct device *dev)
>> > struct device_driver *drv = dev->driver;
>> > int ret = 0;
>> >
>> > + platform_pm_resume_hook(dev);
>> > +
>> > if (!drv)
>> > return 0;
>> >
>> > @@ -786,6 +812,8 @@ static int platform_pm_resume_noirq(struct device *dev)
>> > struct device_driver *drv = dev->driver;
>> > int ret = 0;
>> >
>> > + platform_pm_resume_noirq_hook(dev);
>> > +
>> > if (!drv)
>> > return 0;
>> >
>>
>> It looks reasonable to me, but I'm not actively involved in PM for the
>> platform bus. Magnus Damm might have some suggestions.
>
> Yes, I think Magnus is the right person to ask for comments.
OK, will post a slighly updated version to a broader audience.
Kevin
next prev parent reply other threads:[~2010-03-17 22:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 23:30 runtime PM: common hooks for static and runtime PM Kevin Hilman
2010-02-04 15:24 ` Alan Stern
2010-02-05 10:43 ` Mark Brown
2010-02-05 15:41 ` Alan Stern
2010-02-05 16:11 ` Mark Brown
2010-02-05 21:40 ` Alan Stern
2010-02-05 22:44 ` Mark Brown
2010-02-06 2:57 ` Alan Stern
2010-02-06 15:46 ` Mark Brown
2010-02-06 16:18 ` Alan Stern
2010-02-08 14:54 ` Alan Stern
2010-02-24 18:14 ` Mark Brown
2010-02-24 18:56 ` Alan Stern
2010-02-24 22:32 ` Mark Brown
2010-02-25 15:26 ` Kevin Hilman
2010-03-16 21:31 ` Kevin Hilman
2010-03-17 14:47 ` Alan Stern
2010-03-17 16:42 ` Kevin Hilman
2010-03-17 17:10 ` Alan Stern
2010-03-17 21:46 ` Rafael J. Wysocki
2010-03-17 22:32 ` Kevin Hilman [this message]
2010-03-18 14:13 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874okepojl.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=damm@igel.co.jp \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.