Messages in this thread | | | Date | Wed, 9 Jun 1999 13:05:53 +0200 | From | Werner Almesberger <> | Subject | Power management (was Re: 2.3 wish: integrate pcmcia into mainstream kernel) |
| |
Alan Cox wrote: > It also has a generic power management framework which may be good to adopt.
Let me briefly introduce that design. The goal is to provide useful power management for devices like battery-powered palmtop computers, like the Psion S5, Geofox One, or eventually WinCE machines.
The current source of the power management can be found in ftp://lrcftp.epfl.ch/pub/people/almesber/psion/crash+burn-22.patch.gz with the core parts in include/asm-arm/arch-clps7110/pm.h and drivers/char/pm_7110.h, and a reasonably clear application example in drivers/char/serial_7110.c. (crash+burn is a series of patches that add support for systems based on the CL-PS7110 system-on-a-chip.)
Also, slide 9 of ftp://lrcftp.epfl.ch/pub/people/almesber/slides/le99-7k.ps.gz should be helpful.
Things happen at several levels:
- each device can be directly switched on or off. It can delay the transition indefinitely, if necessary (e.g. you won't want to power down a SCSI interface during a transfer). Requests are serialized. - each device has an idle timer associated with it. Whenever the device does something "interesting", it resets the idle time. When the device reaches its idle time, it is switched off. - when all other devices are asleep, the CPU itself can be put to sleep (e.g. auto-power-off on portable devices) - there is an instant global switch on/off, mainly to give users a clear and reliable way to bring down the system (e.g. before changing batteries, or when boarding a plane) - all the things above are in the kernel, accessible via /proc - more advanced policy, e.g. different timeouts depending on power levels or whether the device runs off batteries, etc., can be implemented by a user-space demon which receives power management events from the kernel via a character device
The design currently has the following limitations, which reflect the situation on most palmtop-type systems:
- only one multi-device policy in the kernel (i.e. enter CPU standby if everything else is asleep) - only one type of switch on/off (e.g. power button)
I would appreciate feedback on cases where this is too inflexible. Note however that the user-space demon if free to implement policies of arbitrary complexity. The purpose of the in-kernel parts is provide the "busy" parts and to allow for useful operation also in the absence of the user-space demon.
There are some more things that I need to fix or plan to look into anyway:
- more efficient idle timer design (e.g. sleep until next event instead of periodic polling) - fix the event model (global switch on/off is full of races and conflicts) - doesn't take into account timers, particularly not long-running ones (e.g. sleep(6*3600); wake_up_owner();) Doing this right will probably mean that a few short-running periodic timers need to be revamped too.
Comments welcome.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |