From: Pavel Machek <pavel@suse.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: linux-pm@lists.osdl.org
Subject: Re: Runtime device power management in userspace
Date: Sat, 24 Dec 2005 01:40:30 +0100 [thread overview]
Message-ID: <20051224004029.GC16043@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0512230706530.13289-100000@monsoon.he.net>
On Pá 23-12-05 07:12:35, Patrick Mochel wrote:
> On Fri, 23 Dec 2005, Holger Macht wrote:
> > We implemented device runtime power management in a userspace application
> > (the powersave daemon). In this specific case, it means to successively
> > put pci devices into D3 powersave mode with writing a numerical '3' to the
> > corresponding power state file.
> >
> > There are two main reasons for us to even doing this:
> >
> > 1. At first, the obvious reason. As mentioned in our research regarding
> > power consumption on this list, there is a very huge potential to
> > save battery power.
> >
> > 2. Due to the fact that this is AFAIK a heavily untested area, as a side
> > effect, we like to get reports about broken modules/drivers and maybe
> > get them fixed.
>
> That's great!
>
> Please note that D3 is only relevant for PCI devices and for ACPI devices.
> The fact that it's the same value for every device in the system is a
> design flaw. Please be aware that the value to write to the device file
> could change, and will be dependent on the type (bus) of device, and quite
> possibly on the device itself. It may not even be '3' for all PCI devices
> in the future, or may be a string rather than 1 character, or simply a '1'
> into a different file.
Is there enough locking in driver core to make this safe?
Ouch and BTW *right* value is _2_, today... because state_store() uses
value from user as a pm_message_t.event. We should at least supply
some hint that it is runtime suspend in pm_message_t.flags --
unfortunately we do not have pm_message_t.flags yet.
Something like this is needed -- userspace should not play with
pm_message_t.state directly. [not even compile tested, have to sleep.]
I guess we should also audit the drivers... It needs locking against
user supplying requests concurently.
> Also, is there source available?
Should be, we are trying to do *Open*SUSE these days ;-))).
Pavel
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -34,12 +34,14 @@ static ssize_t state_store(struct device
{
pm_message_t state;
char * rest;
- int error = 0;
+ int error = 0, i;
- state.event = simple_strtoul(buf, &rest, 10);
+ i = simple_strtoul(buf, &rest, 10);
+ state.event = PM_EVENT_SUSPEND;
+ state.flags = PM_FLAGS_RUNTIME;
if (*rest)
return -EINVAL;
- if (state.event)
+ if (i)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
diff --git a/include/linux/pm.h b/include/linux/pm.h
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -140,6 +140,7 @@ struct device;
typedef struct pm_message {
int event;
+ int flags;
} pm_message_t;
/*
@@ -165,6 +166,8 @@ typedef struct pm_message {
#define PM_EVENT_FREEZE 1
#define PM_EVENT_SUSPEND 2
+#define PM_FLAGS_RUNTIME 1
+
#define PMSG_FREEZE ((struct pm_message){ .event = PM_EVENT_FREEZE, })
#define PMSG_SUSPEND ((struct pm_message){ .event = PM_EVENT_SUSPEND, })
#define PMSG_ON ((struct pm_message){ .event = PM_EVENT_ON, })
--
Thanks, Sharp!
next prev parent reply other threads:[~2005-12-24 0:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-23 14:30 Runtime device power management in userspace Holger Macht
2005-12-23 15:12 ` Patrick Mochel
2005-12-24 0:40 ` Pavel Machek [this message]
2005-12-26 20:43 ` Patrick Mochel
2005-12-26 22:33 ` Pavel Machek
2005-12-27 18:59 ` Patrick Mochel
2005-12-27 19:22 ` Pavel Machek
2005-12-27 19:29 ` Patrick Mochel
2005-12-27 19:41 ` Pavel Machek
2005-12-27 20:40 ` Patrick Mochel
2005-12-27 21:06 ` Pavel Machek
2005-12-26 22:47 ` Alan Stern
2005-12-27 17:29 ` Pavel Machek
2005-12-27 17:36 ` Randy.Dunlap
2005-12-24 15:31 ` Holger Macht
2005-12-26 20:58 ` Patrick Mochel
2005-12-27 20:04 ` Pavel Machek
2005-12-27 20:54 ` Patrick Mochel
2005-12-23 15:17 ` Alan Stern
2005-12-24 0:41 ` Pavel Machek
2005-12-24 0:43 ` Pavel Machek
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=20051224004029.GC16043@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=linux-pm@lists.osdl.org \
--cc=mochel@digitalimplant.org \
/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.