What woke system up?

What woke system up?

[Todd Poynor]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

Next in our series of wakeup patches: a consumer electronics maker asked
for a userspace interface to inquire what woke the system up, in order
to present different behaviors depending on the wakeup source.  This is
to be encouraged, as it places these kinds of policy decisions into the
power policy application and out of the kernel.

So here's a quick try at adding a /sys/power/waker attribute and a
pm_add_waker() kernel function that either drivers or board PM code can
use to add (so far format-free) strings useful for telling what woke the
system up.  The idea is that a buffer of these strings is cleared at
each suspend and added to by the platform's resume path and/or driver
resume methods.

I'll send a patch or two for embedded boards showing how
this could be used for SoC-specific wakeup sources.

Any interest in this or something like it for Linux in general, or any
other suggestions?  Thanks -- Todd

Add /sys/power/waker and pm_add_waker() for board-specific wakeup info.

Index: linux-2.6.15-rc4/kernel/power/main.c
===================================================================
--- linux-2.6.15-rc4.orig/kernel/power/main.c
+++ linux-2.6.15-rc4/kernel/power/main.c
@@ -103,11 +103,18 @@ static int suspend_prepare(suspend_state
 }
 
 
+#define WAKERINFO_LEN 1024
+
+static char *wakerinfo;
+
 static int suspend_enter(suspend_state_t state)
 {
 	int error = 0;
 	unsigned long flags;
 
+	if (wakerinfo)
+		*wakerinfo = '\0';
+
 	local_irq_save(flags);
 
 	if ((error = device_power_down(PMSG_SUSPEND))) {
@@ -281,8 +288,35 @@ static ssize_t state_store(struct subsys
 
 power_attr(state);
 
+void pm_add_waker(char * buf)
+{
+	if (! wakerinfo) {
+		wakerinfo = kmalloc(WAKERINFO_LEN, GFP_KERNEL);
+
+		if (wakerinfo)
+			*wakerinfo = '\0';
+	}
+
+	if (wakerinfo)
+		strlcat(wakerinfo, buf, WAKERINFO_LEN);
+}
+
+static ssize_t waker_show(struct subsystem * subsys, char * buf)
+{
+	return sprintf(buf,"%s\n", wakerinfo ? wakerinfo : "");
+}
+
+static ssize_t waker_store(struct subsystem * subsys, const char * buf,
+			   size_t n)
+{
+	return -EINVAL;
+}
+
+power_attr(waker);
+
 static struct attribute * g[] = {
 	&state_attr.attr,
+	&waker_attr.attr,
 	NULL,
 };
 
Index: linux-2.6.15-rc4/include/linux/pm.h
===================================================================
--- linux-2.6.15-rc4.orig/include/linux/pm.h
+++ linux-2.6.15-rc4/include/linux/pm.h
@@ -130,7 +130,7 @@ struct pm_ops {
 extern void pm_set_ops(struct pm_ops *);
 extern struct pm_ops *pm_ops;
 extern int pm_suspend(suspend_state_t state);
-
+extern void pm_add_waker(char * buf);
 
 /*
  * Device power management


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1398 bytes --]


On Tue, 20 Dec 2005, Todd Poynor wrote:

> Next in our series of wakeup patches: a consumer electronics maker asked
> for a userspace interface to inquire what woke the system up, in order
> to present different behaviors depending on the wakeup source.  This is
> to be encouraged, as it places these kinds of policy decisions into the
> power policy application and out of the kernel.
>
> So here's a quick try at adding a /sys/power/waker attribute and a
> pm_add_waker() kernel function that either drivers or board PM code can
> use to add (so far format-free) strings useful for telling what woke the
> system up.  The idea is that a buffer of these strings is cleared at
> each suspend and added to by the platform's resume path and/or driver
> resume methods.
>
> I'll send a patch or two for embedded boards showing how
> this could be used for SoC-specific wakeup sources.
>
> Any interest in this or something like it for Linux in general, or any
> other suggestions?  Thanks -- Todd

What about stashing a pointer to the device that did the wakeup, then
using a symlink to point to the sysfs directory of that device? That way,
instead of some arbitrary string, like "wake wake wake", you can
definitively know what device it was, as well as any other status..

You can remove the symlink on suspend, just like you could clear the
string, and re-add it on resume.

Thanks,


	Patrick


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Todd Poynor]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

On Tue, Dec 20, 2005 at 06:11:40PM -0800, Patrick Mochel wrote:
> What about stashing a pointer to the device that did the wakeup, then
> using a symlink to point to the sysfs directory of that device? That way,
> instead of some arbitrary string, like "wake wake wake", you can
> definitively know what device it was, as well as any other status..
> 
> You can remove the symlink on suspend, just like you could clear the
> string, and re-add it on resume.

Sounds good, here's a new version that does just that.  Any further
improvements?  Thanks -- Todd

Add /sys/power/waker and pm_set_waker() for querying which device woke
the system.

Signed-off-by: Todd Poynor <tpoynor@mvista.com>

Index: linux-2.6.15-rc4/kernel/power/main.c
===================================================================
--- linux-2.6.15-rc4.orig/kernel/power/main.c
+++ linux-2.6.15-rc4/kernel/power/main.c
@@ -15,6 +15,7 @@
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/pm.h>
+#include <linux/device.h>
 
 
 #include "power.h"
@@ -27,6 +28,8 @@ DECLARE_MUTEX(pm_sem);
 struct pm_ops *pm_ops;
 suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;
 
+static void clear_waker(void);
+
 /**
  *	pm_set_ops - Set the global power method table. 
  *	@ops:	Pointer to ops structure.
@@ -108,6 +111,7 @@ static int suspend_enter(suspend_state_t
 	int error = 0;
 	unsigned long flags;
 
+	clear_waker();
 	local_irq_save(flags);
 
 	if ((error = device_power_down(PMSG_SUSPEND))) {
@@ -281,6 +285,16 @@ static ssize_t state_store(struct subsys
 
 power_attr(state);
 
+static void clear_waker(void)
+{
+	sysfs_remove_link(&power_subsys.kset.kobj, "waker");
+}
+
+void pm_set_waker(struct device *dev)
+{
+	sysfs_create_link(&power_subsys.kset.kobj, &dev->kobj, "waker");
+}
+
 static struct attribute * g[] = {
 	&state_attr.attr,
 	NULL,
Index: linux-2.6.15-rc4/include/linux/pm.h
===================================================================
--- linux-2.6.15-rc4.orig/include/linux/pm.h
+++ linux-2.6.15-rc4/include/linux/pm.h
@@ -131,6 +131,9 @@ extern void pm_set_ops(struct pm_ops *);
 extern struct pm_ops *pm_ops;
 extern int pm_suspend(suspend_state_t state);
 
+struct device;
+
+extern void pm_set_waker(struct device *dev);
 
 /*
  * Device power management


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Hi!

> Next in our series of wakeup patches: a consumer electronics maker asked
> for a userspace interface to inquire what woke the system up, in order
> to present different behaviors depending on the wakeup source.  This is
> to be encouraged, as it places these kinds of policy decisions into the
> power policy application and out of the kernel.
> 
> So here's a quick try at adding a /sys/power/waker attribute and a
> pm_add_waker() kernel function that either drivers or board PM code can
> use to add (so far format-free) strings useful for telling what woke the
> system up.  The idea is that a buffer of these strings is cleared at
> each suspend and added to by the platform's resume path and/or driver
> resume methods.
> 
> I'll send a patch or two for embedded boards showing how
> this could be used for SoC-specific wakeup sources.
> 
> Any interest in this or something like it for Linux in general, or any
> other suggestions?  Thanks -- Todd

Well, idea may be okay but patch is ugly.

> Index: linux-2.6.15-rc4/kernel/power/main.c
> ===================================================================
> --- linux-2.6.15-rc4.orig/kernel/power/main.c
> +++ linux-2.6.15-rc4/kernel/power/main.c
> @@ -103,11 +103,18 @@ static int suspend_prepare(suspend_state
>  }
>  
>  
> +#define WAKERINFO_LEN 1024
> +
> +static char *wakerinfo;

Can you just allocate it statically? And use some reasonable length.

> +void pm_add_waker(char * buf)

char *buf

> +{
> +	if (! wakerinfo) {

Please don't use space between "!" and variable.

								Pavel
-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Leo L. Schwab]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Wed, Dec 21, 2005 at 07:46:30PM -0800, Todd Poynor wrote:
> On Tue, Dec 20, 2005 at 06:11:40PM -0800, Patrick Mochel wrote:
> > What about stashing a pointer to the device that did the wakeup, then
> > using a symlink to point to the sysfs directory of that device?  [ ... ]
> 
> Sounds good, here's a new version that does just that.  [ ... ]

	I'm entering this discussion late, but if I were putting this
together:
	- There would be a single file named /sys/power/wake,
	- Upon resume, the file would contain lines of plaintext of the
	  format:

		device: reason

	- 'device' names the device that performed the wakeup.  'device'
	  could be either a sysfs path or a /dev/blah/blah path (sysfs is
	  probably better, if more verbose, as it remains consistent
	  regardless of how /dev is configured),
	- 'reason' is free-form text, supplied by the device performing the
	  wakeup, and is entirely device-dependent.

	This approach allows multiple wakeup sources (rare, but possible),
and also allows a single multifunction device to report multiple reasons for
a wakeup.  It's also darned simple to parse.

	IMHO, of course.

					Schwab

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Wed 04-01-06 10:21:16, Leo L. Schwab wrote:
> On Wed, Dec 21, 2005 at 07:46:30PM -0800, Todd Poynor wrote:
> > On Tue, Dec 20, 2005 at 06:11:40PM -0800, Patrick Mochel wrote:
> > > What about stashing a pointer to the device that did the wakeup, then
> > > using a symlink to point to the sysfs directory of that device?  [ ... ]
> > 
> > Sounds good, here's a new version that does just that.  [ ... ]
> 
> 	I'm entering this discussion late, but if I were putting this
> together:
> 	- There would be a single file named /sys/power/wake,
> 	- Upon resume, the file would contain lines of plaintext of the
> 	  format:
> 
> 		device: reason

sysfs should be 'one value per file'. 
						Pavel

-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2132 bytes --]


On Wed, 4 Jan 2006, Leo L. Schwab wrote:

> On Wed, Dec 21, 2005 at 07:46:30PM -0800, Todd Poynor wrote:
> > On Tue, Dec 20, 2005 at 06:11:40PM -0800, Patrick Mochel wrote:
> > > What about stashing a pointer to the device that did the wakeup, then
> > > using a symlink to point to the sysfs directory of that device?  [ ... ]
> >
> > Sounds good, here's a new version that does just that.  [ ... ]
>
> 	I'm entering this discussion late, but if I were putting this
> together:
> 	- There would be a single file named /sys/power/wake,
> 	- Upon resume, the file would contain lines of plaintext of the
> 	  format:
>
> 		device: reason
>

Unless it's a single binary blob, we want to keep sysfs files to contain a
single discrete value.

> 	- 'device' names the device that performed the wakeup.  'device'
> 	  could be either a sysfs path or a /dev/blah/blah path (sysfs is
> 	  probably better, if more verbose, as it remains consistent
> 	  regardless of how /dev is configured),

We don't know the /dev path at all from the kernel (and one can't easily
ascertain the sysfs path from a device node entry). So, it would have to
be a sysfs path.

> 	- 'reason' is free-form text, supplied by the device performing the
> 	  wakeup, and is entirely device-dependent.

What is an example of a reason? Is it more explicit than e.g. "button
pressed"?

> 	This approach allows multiple wakeup sources (rare, but possible),
> and also allows a single multifunction device to report multiple reasons for
> a wakeup.  It's also darned simple to parse.

A single multi-function device should have multiple devices in the sysfs
tree. So, if we allowed multiple symlinks to exist pointing to all of the
wakeup devices, and provided a "wakeup-reason" file in each of the
device's directories, then we could provide for multiple wakeup sources.

The reason I push the symlink idea is because it's the easiest way to
convey a device path via sysfs, and it allows us to stay with one value
per file, while achieving the functionality you describe.

Out of curiosity, are there really cases where there is > 1 wakeup
device?

Thanks,


	Patrick


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: What woke system up?

[Todd Poynor]

Patrick Mochel wrote:
> Out of curiosity, are there really cases where there is > 1 wakeup
> device?

I will guess there are systems in which software will be presented with 
more than one candidate device that may have woken the system (for 
example, more than one interrupt is pending at resume time, and this is 
the only information available on what the wakeup source was).  But I 
don't have a definite example of such a system.   So far I've only 
looked at 2 embedded platforms.  One of 'em devotes registers 
specifically to what woke up the system, and has not yet turned up 2 
wakers, but I haven't hit this very hard yet.  The other I can't get 
useful info out of as of yet.

-- 
Todd