From: Kevin Hilman <khilman@deeprootsystems.com>
To: Greg KH <gregkh@suse.de>
Cc: linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org,
Magnus Damm <damm@opensource.se>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Dmitry Torokhov <dtor@mail.ru>,
Eric Miao <eric.y.miao@gmail.com>
Subject: Re: [RFC/PATCH] platform_bus: allow custom extensions to system PM methods
Date: Thu, 18 Mar 2010 09:57:06 -0700 [thread overview]
Message-ID: <87bpellg9p.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20100317234414.GA23319@suse.de> (Greg KH's message of "Wed\, 17 Mar 2010 16\:44\:14 -0700")
Greg KH <gregkh@suse.de> writes:
> On Wed, Mar 17, 2010 at 04:18:15PM -0700, Kevin Hilman wrote:
>> 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 also extend the system PM methods with
>> custom hooks so runtime PM and system PM extensions can be managed
>> together by custom platform-specific code.
>
> Wow, that's scary, I didn't realize that was done for the runtime stuff.
>
> What would you be replacing these functions with for your platform that
> would require it to be in arch-specific code?
I'm basically copying the existing functions and extending them with
platform-specific code to manage device clocks and other PM HW state.
IOW, I still call the drivers PM methods, but also take care of some
platform specific PM HW management. This is just like the runtime PM
hooks: platform-specific code + calling drivers runtime PM methods.
On my platform (TI OMAP), the code to handle device PM is common for
all devices, so for runtime PM, I'm taking care of it at the bus
level. At the hardware level, there's really no difference between
runtime and system PM, so I want to take advantage of the same
platform specific code for system PM
Initially, rather than making the system PM methods themselves weak, I
added some weak hooks that could be overridden instead (see test patch
below). The problem with that is that it is not as flexible if you
want to run some custom code before and/or after calling the drivers
PM methods. To be more flexible, using this approach, we'd probably
need pre- and post- hooks to be used before and after the driver's PM
methods are called. Rather than add all these hooks, I decided it was
cleaner to just allow override of the primary methods themselves,
which parallels the runtime PM approach.
Kevin
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
+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;
next prev parent reply other threads:[~2010-03-18 16:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 23:18 [RFC/PATCH] platform_bus: allow custom extensions to system PM methods Kevin Hilman
2010-03-17 23:44 ` Greg KH
2010-03-18 16:57 ` Kevin Hilman [this message]
2010-03-18 17:20 ` Greg KH
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=87bpellg9p.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=damm@opensource.se \
--cc=dtor@mail.ru \
--cc=eric.y.miao@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox