public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [RFC] dynamic device power management proposal
@ 2007-03-22 13:39 Scott E. Preece
  2007-03-22 13:48 ` Oliver Neukum
                   ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Scott E. Preece @ 2007-03-22 13:39 UTC (permalink / raw)
  To: pavel; +Cc: linux-pm


| From: Pavel Machek<pavel@ucw.cz>
| 
| On Thu 2007-03-22 00:49:51, Dmitry Krivoschekov wrote:
| > Amit Kucheria wrote:
| > > On 3/21/07, Shaohua Li <shaohua.li@intel.com> wrote:
| > >> On Wed, 2007-03-21 at 02:30 +0800, Pavel Machek wrote:
| > >
| > >>> No, that's not how it works; look at hda_audio, it already has
| > >>> powersave. Just power down audio card 5 seconds after its control file
| > >>> is closed.
| > >> It's another case of doing policy in a driver.
| > >>
| > >
| > > IMHO, this kind of policy is best handled inside the driver because it
| > > is specific to the hardware. This will ensure that the driver will
| > > just work on every distro without some userspace policy being present
| > > and setup _correctly_.
| > 
| > It some circumstances this policy may increase power consumption
| > but not decrease it. Consider the case of repeatable operation,
| 
| And what... that happens. Lets not break our design because you can
| think of very contrieved corner case.
| 
| > something like periodic sound beep, with period of 5s.
| > In this case, a driver implementing the policy will periodically
| > suspend/resume a number of devices - audio controller, codec, ADC,
| > but the operation  itself (suspending/resuming) will consume
| > more power than power consumed by these devices in case they
| > left running for a 5s. In such a case you may want to change
| > the predefined  value or  just  disable the policy.
| 
| > Yes, we may just not close a sound device file, but phone
| > applications I've seen, do close the file.
| 
| Fix the app, then.
---

I would normally call designs that expect important functions (like
power on/power off) to happen as side effects of other operations (like
opening and closing files) broken to begin with. It's still a bad idea
to hide policy inside the driver.

There's nothing contrived or corner-case-ish about cyclic operations in
a world where media players, animations, etc., are utterly commonplace.
And latency may be ignorable in a laptop environment, but it absolutely
isn't in embedded devices, which users expect to operate immediately, as
though they were gear-driven rather than computer-driven.

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC] dynamic device power management proposal
@ 2007-03-22 19:18 Scott E. Preece
  0 siblings, 0 replies; 42+ messages in thread
From: Scott E. Preece @ 2007-03-22 19:18 UTC (permalink / raw)
  To: stern; +Cc: linux-pm, pavel


| From: Alan Stern<stern@rowland.harvard.edu>
| 
| On Thu, 22 Mar 2007, Scott E. Preece wrote:
| 
| > I would normally call designs that expect important functions (like
| > power on/power off) to happen as side effects of other operations (like
| > opening and closing files) broken to begin with. It's still a bad idea
| > to hide policy inside the driver.
| 
| Even though other people have already answered this, I'd like to add my 
| own comments.
| 
| Firstly, doing power on/power off as side effects of other operations is 
| _not_ a policy choice.  It is a design principle:
| 
| 	When device D has been idle for more than N ms, it should be
| 	put in a low-power state (unless such state changes have been
| 	disabled for D by userspace).
| 
| Of course N will vary for different D's, and the exact choice of N _is_
| policy.  Thus N should be exposed and configurable by userspace.  So
| should the ability to disable the state changes.  But the principle
| above isn't a policy, it is part of the design.
| 
| Secondly, this principle _requires_ that power on/power off occur as side 
| effects of other operations, since those other operations affect whether 
| or not the device is idle.
| 
| If anybody wants to argue against the principle itself, then go ahead and
| say so.  I, for one, don't see anything objectionable about it.
---

I have absolutely no problem with the principle, as long as things are
as you describe - the timing is exposed and configurable and there is
the ability to disable the transitions.

I also have no problem with operations interacting with power on/off
when they clearly have to (sure, if the device is off and the user
writes to it, you probably want to turn it on), but open and close are
different in that respect from read and write - they simply delimit the
time over which operations may be requested and don't inherently imply
anything about the power-state of the device. There is no reason
whatever that a device has to be powered on all the time its driver has
it recorded as open and there's no reason to assume it's OK to power it
off when it's closed.

I disagree with you about whether it's policy (it seems to me that
deciding when to apply a mechanism is exactly what policy is), but it's
not worth arguing about.

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC] dynamic device power management proposal
@ 2007-03-22 19:05 Scott E. Preece
  2007-03-27 12:05 ` Pavel Machek
  0 siblings, 1 reply; 42+ messages in thread
From: Scott E. Preece @ 2007-03-22 19:05 UTC (permalink / raw)
  To: pavel; +Cc: linux-pm


| From: Pavel Machek<pavel@ucw.cz>
| 
| Hi!
| 
| > | > Yes, we may just not close a sound device file, but phone
| > | > applications I've seen, do close the file.
| > | 
| > | Fix the app, then.
| > ---
| > 
| > I would normally call designs that expect important functions (like
| > power on/power off) to happen as side effects of other operations (like
| > opening and closing files) broken to begin with. It's still a bad idea
| > to hide policy inside the driver.
| 
| Then you are welcome to go design your own operating system.
| 
| I certinaly do not want open() on powered down /dev/dsp to succeed
| with /dev/dsp powered down.
---

I don't, either. I just don't want it to power down unless I've said
it's OK. I would be fine with an API that cleanly tells the device not
to power down on its own. 

You said "let's not break our designs for corner cases"; I simply
expressed the opinion that that aspect of the design seemed broken, by
normal software design criteria - don't let important things happen as
side effects.

---
| 
| > There's nothing contrived or corner-case-ish about cyclic operations in
| > a world where media players, animations, etc., are utterly
| > commonplace.
| 
| Yep? And you close your sound device between those?
---

We close it between some kinds of cyclic operations. We'd like to be
able to be finer grained in the future.

---
| > And latency may be ignorable in a laptop environment, but it absolutely
| > isn't in embedded devices, which users expect to operate immediately, as
| > though they were gear-driven rather than computer-driven.
| 
| What latency are you talking about? Powering up piece of hw takes one
| milisecond or something. If your /dev/dsp takes 3 seconds to power up,
| you probably need userspace policy daemon. But that is not the case,
| hw takes few miliseconds to wake up.
---

Sure, but *some* devices take substantially longer to power up or
down.  If you insist that the driver should make the power down
decision, then you lump high-latency and low-latency devices together,
even though high-latency devices might be better served by separating
the semantics.

scott

-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC] dynamic device power management proposal
@ 2007-03-21 20:19 Scott E. Preece
  2007-03-21 21:45 ` Pavel Machek
  2007-03-26 13:53 ` Amit Kucheria
  0 siblings, 2 replies; 42+ messages in thread
From: Scott E. Preece @ 2007-03-21 20:19 UTC (permalink / raw)
  To: kucheria.amit; +Cc: linux-pm, pavel


| From: "Amit Kucheria"<kucheria.amit@gmail.com>
| 
| On 3/21/07, Shaohua Li <shaohua.li@intel.com> wrote:
| > On Wed, 2007-03-21 at 02:30 +0800, Pavel Machek wrote:
| 
| > > No, that's not how it works; look at hda_audio, it already has
| > > powersave. Just power down audio card 5 seconds after its control file
| > > is closed.
| > It's another case of doing policy in a driver.
| >
| 
| IMHO, this kind of policy is best handled inside the driver because it
| is specific to the hardware. This will ensure that the driver will
| just work on every distro without some userspace policy being present
| and setup _correctly_.
---

On an embedded device, the knowledge of when it makes sense to keep a
disk spinning, to avoid latency when it's needed next, versus when it
makes sense to spin it down to save power, probably fits better in user
space than in the kernel. In such a case there's likely to be a "master"
application (in our case, for instance, "the phone application") that
owns a lot of knowledge about whole-system state and user interactions.
Not, of course, that we have a disk to spin down.

On the other hand, we also have devices that do their own power saving,
largely in cases where they don't have latency issues large enough to
worry about.

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [RFC] dynamic device power management proposal
@ 2007-03-19  9:08 Shaohua Li
  2007-03-19 15:44 ` Alan Stern
                   ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Shaohua Li @ 2007-03-19  9:08 UTC (permalink / raw)
  To: linux-pm

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

Runtime device power management or dynamic device power management
(dpm).

Why dpm: 
     1. put an idle device into low power state to save power 
     2. speed up S3/S4. In resume time, we could resume devices only as
        the devices are used. In suspend time, we could skip suspended
        devices. (suspend/resume a device equals to change device state)

Basically we need device driver support, a kernel framework and a policy
(determine when to change a device’s power state).

I think we need answer below questions:
1. How to present device’s power info/control interface to policy.
Unlike ACPI Dx state, a device’s power state might depend on several
parameters, like voltage/clock. We must change several parameters in the
meantime to switch device’s power state.
2. How to handle devices dependences. For example, for a PCI endpoint
and a pci bridge above the pci endpoint, we should suspend pci endpoint
device first and then suspend pci bridge and vice versa in resume. On
the other hand, two devices might not have such relationship. Two
devices might haven’t any bus relationship. Eg, in embedded system, a
clock might drive several devices under different buses.
3. How to detect if a device is idle.
4. where should policy be, kernel/userspace. Userspace policy is
flexible, but userspace policy has some limitations like being swapped
out. The limitations don’t impact suspend device, but resume device
should be quick, eg suspended device should be resumed quickly soon
after new service request is coming.

My proposal: 
     1. device’s power parameters. If a device’s power state depends on
        several parameters, we can map different parameters combining
         to a single index, which looks like ACPI Dx state. In this way,
        dpm framework and policy have a generic interface to get/set
        device’s state. Each state exports some info, including this
        state’s power consumption/latency. Device driver can export
        extra info to policy, dpm framework doesn’t handle the extra
        info, but policy can. 
     2. The device dependence varies from different systems especially
        for embedded system. The idea is dpm framework handles device
        dependence (like, resume a device’s parent before resume the
        device itself), and policy inputs the dependence data to dpm
        framework. As device dependence exists, device driver shouldn’t
        directly resume a device. Instead, let dpm framework resumes the
        device and handle dependence in the meantime. To input
        dependence data, policy should know device’s unique name and dpm
        framework can get corresponding dpm device from the name.
        Different buses have different device naming methods. To assign
        a unified name to each device, I just give each device an id
        regardless which bus the device is on. 
     3. detect if a device is idle. The idea is each device has a busy
        timestamp. Every time the driver wants to handle the device,
        driver will update the timestamp. Policy can poll the timestamp
        to determine if the device is idle. 
     4. policy position. The idea is policy resides on userspace. Dpm
        framework exports device’s busy timestamp, state info,
        dependence setting to userspace. According to the info, policy
        suspends a device in specific time. Resuming a device is
        directly done by dpm framework in kernel.

So in my proposal, dpm framework will provide some APIs for device
driver and export some info to userspace and a userspace policy
determines when to suspend a device. Attached code is my prototype to
demonstrate my idea (it even can’t be compiled).  With the framework,
driver/policy should do:
===================device driver==========================
int foo() //all service routines of the driver should do
{ 
            //wakeup the device if it’s suspended
            dpm_active_device();
            … //do service
            /* if necessary, mark the device busy to not suspend the
device */
            dpm_mark_device_busy();
            …//do service
}

struct dpm_driver my_driver {
            .init = xxx_init, //initialize the dpm device, eg. the
device’s state info
            .get_state = xxx_get_state, //get current device’s power
state
            .set_state = xxx_set_state, //set current device’s power
state. Maybe just use .suspend/.resume here
};

driver_init()
{
            dpm_device_bind_driver(dev->dpm, &my_driver);
}

=================user interface======================
Dpm framework will export below sysfs info for every dpm device:
            ../dpm/
                        `id      /*dpm device’s unique id*/
                        `state0     /*all device states’ info*/
                                    `power
                                    `latency
                        `stateX
                                    `power
                                    `latency
                        `state       /* get/set device state */
                        `busy_timestamp   /* device’s busy timestamp */
                        `set_dependence  /* interface to set device
dependence */
                        `status        /* device’s status */
===================policy===========================
/* initialize device dependences */
Write one device’s id to other device’s set_dependence sysfs file.

We consider two type devices:
1. for soundcard, policy does:
a. Setup a timer, the timer polls soundcard’s busy_timestamp sysfs file.
b. if the timer found soundcard is idle for a long time, write the
device’s state sysfs file, and sound card to low power state.
c. policy does nothing to resume soundcard. Soundcard driver’s service
routine will call ’dpm_active_device’ to resume the device
 
2. For keyboard or mouse, policy does:
a. setup a timer, the timer polls keyboard’s busy_timestamp sysfs file.
b. if the timer found keyboard is idle for a long time, write LCD’s
state sysfs file to close LCD.
c. After LCD is closed, policy polls keyboard’s busy_timestamp sysfs
file.
d. if the content changed of the file (maybe using inotify), policy will
open LCD

==================suspend/resume (S3/S4)=====================
1. Device suspend follows current Linux scheme, but ignore suspended
device
2. in resume, don’t do device resume. Device will automatically resume
on demand. No policy application involved in the process, as dpm
framework will be responsible for device resume.

This is my preliminary design, and I’d like to listen to your opinions.

Thanks,
Shaohua

[-- Attachment #2: pm.tgz --]
[-- Type: application/x-compressed-tar, Size: 2367 bytes --]

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



^ permalink raw reply	[flat|nested] 42+ messages in thread
end of thread, other threads:[~2007-03-27 12:19 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-22 13:39 [RFC] dynamic device power management proposal Scott E. Preece
2007-03-22 13:48 ` Oliver Neukum
2007-03-22 14:01 ` Pavel Machek
2007-03-22 14:45 ` Alan Stern
2007-03-22 18:53   ` David Brownell
  -- strict thread matches above, loose matches on Subject: below --
2007-03-22 19:18 Scott E. Preece
2007-03-22 19:05 Scott E. Preece
2007-03-27 12:05 ` Pavel Machek
2007-03-27 12:19   ` Oliver Neukum
2007-03-21 20:19 Scott E. Preece
2007-03-21 21:45 ` Pavel Machek
2007-03-26 13:53 ` Amit Kucheria
2007-03-19  9:08 Shaohua Li
2007-03-19 15:44 ` Alan Stern
2007-03-20  1:06   ` Shaohua Li
2007-03-20 14:58     ` Alan Stern
2007-03-21  1:43       ` Shaohua Li
2007-03-21 14:44         ` Alan Stern
2007-03-22  4:42   ` Len Brown
2007-03-22 11:56     ` Jim Gettys
2007-03-22 19:28       ` David Brownell
2007-03-22 13:20     ` Pavel Machek
2007-03-22 13:44       ` Oliver Neukum
2007-03-22 13:56         ` Pavel Machek
2007-03-22 14:18           ` Oliver Neukum
2007-03-22 14:22             ` Pavel Machek
2007-03-22 14:26               ` Oliver Neukum
2007-03-22 14:35                 ` Pavel Machek
2007-03-22 19:41     ` David Brownell
2007-03-22 19:58   ` David Brownell
2007-03-20 18:30 ` Pavel Machek
2007-03-21  1:34   ` Shaohua Li
2007-03-21 15:21     ` Amit Kucheria
2007-03-21 21:49       ` Dmitry Krivoschekov
2007-03-21 22:54         ` Pavel Machek
2007-03-21 21:39     ` Pavel Machek
2007-03-22  3:09       ` Shaohua Li
2007-03-22 13:13         ` Pavel Machek
2007-03-22 19:20       ` David Brownell
2007-03-22 20:32         ` Alan Stern
2007-03-22 20:02 ` David Brownell
2007-03-22 22:10   ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox