Date:	Thu, 18 Mar 2010 09:57:06 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Magnus Damm <damm@...nsource.se>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Dmitry Torokhov <dtor@...l.ru>,
	Eric Miao <eric.y.miao@...il.com>
Subject: Re: [RFC/PATCH] platform_bus: allow custom extensions to system PM methods

Greg KH <gregkh@...e.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;
 






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists