[linux-pm] New comer in the linux-pm list
David GIGUET
david.giguet at sagem.com
Thu Nov 20 04:40:56 PST 2008
I am forwarding an e-mail from N. PAJANI, one of our collaborator.
Hi all
I have made some googling and read some code from the kernel, but I did
not managed to find a "power management scheme" outside of APM or ACPI to
fit my needs.
My goal is to have something relevent for embeded devices (or at least
battery powered), not only servers, desktop or laptops, though it may
apply to these.
For example on a cellphone, when you switch to "silent mode" what need do
you have to power the audio amplifier, and maybe the audio module inside
the SOC may be stopped, saving more power.
Or fully powering Wifi or Ethernet when they are not in use on a "netbook"
is also an unuseful loss of power.
But from my trips on the net I did not find any way to stop drivers
individually.
I'm working on ARM right now, but this is relevent for any architecture,
even x86 (from what I understand, ACPI does system level power management,
not device level, but using an ACPI compliant way would be best if
possible).
I have thought of not loading the drivers for the unwanted devices, but I
figured out that this is not the right solution, first because we don't
know the state of the device when we come to run on the hardware, secondly
because most of the drivers just unregister themselves upon unload, and
don't really turn off the device.
I have not yet gone deep inside the kernel to look for what's already
there, but I'd like some advices from others on how to create the new
functionnality I need.
If in fact I'm asking something that has already been discussed somewhere
else, please let me know where, so I can have a look.
Here is what I have planned for the implementation:
Use the existing functionnalities and layout created by
"drivers/base/power/main.c" and implement some callbacks in sysfs so that
any device may be suspended or resumed individually.
First,
The sysfs tree will gain a /sys/*pm*/ directory (replace *pm* by a name we
should define)
This directory will contain links to some of the
/sys/****per_device***/power/ directories (those able to perform
powermanagement). The goal behind this is to allow userspace programs to
find quickly which devices are "individual power management capable". It
may be a complete bus (PCI for example) if the bus is capable of handling
dependencies (shutting down all of his devices for example).
Then,
* Add in the device's power dir a way to call the suspend and resume, so
that the device can be shut down and resumed individually.
* Move any existing callback related to power management in the device's
dir to the power dir (in my case for example, the LCD backlight brightness
and backlight power callbacks).
* Add a /sys/****per_device***/power/capabilities/ directory containing
read-only files with a syntax to be defined to advertise for capabilities
(min/max levels, on/off, ... ?)
If anyone is interrested in this, can contribute ideas, or has already
done this (even in another way), please feel free to give some info here.
If you want to say this is madness, but don't give hint of what's the
better way, please save your time (and mine).
Thanks.
And have fun :)
+++
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/linux-pm/attachments/20081120/4a577d28/attachment.htm
More information about the linux-pm
mailing list