How to do power save on a arm based Embedded Linux system?

Question

Hi

I plan to develop a nice little application that will run on a arm based embedded linux platform, however since that platform will be battery powered I'm searching for relevant information on how to handle powersave. It is kind of important to get decent battery time.

I think the linux kernel implemented some support for this, but I can't find any documentation on this subject.

Any input on how to design my program and the system is welcome, and how the linux kernel tries to solves this type of problem is welcome.

How much do the program in user space need to do? And do you need to modify the kernel? What kernel system calls/api:s are good to know about?

Thanks Johan

---

Update:

It seems like the "Free Electrons" has produced some nice presentations on this subject.

• http://free-electrons.com/services/power-management/
• http://free-electrons.com/docs/power
• http://free-electrons.com/docs/optimizations

But maybe someone else has even more information on this subject?

---

Update:

It seems like Adam Shiemke:s idea to go look at the MeeGo project the best tip so far. It may be the best battery powered Embedded Linux project out there at this moment. And Nokia is usually kind of good at this type of thing.

---

Update:

One has to be careful about Android since it has a "modified" Linux kernel in the bottom, and some of the things google has done is not in the baseline/normal linux kernels. I think that some of their power management ideas could be troublesome to reuse for other projects.

Answer 1

I haven't actually done this, but I have experience with the two apart (Linux and embedded power management). There are two main Linux distributions that come to mind when thinking about power management, Android and MeeGo. MeeGo uses (as far as I can tell) an unmodified 2.6 kernel with some extras hanging on. I wasn't able to find a lot on exactly what their power management strategy is, although I suspect more will be coming out about it in the near future as the product approaches maturity.

There is much more information available on Android, however. They run a fairly heavily modified 2.6 kernel. You can see a good bit on the different strategies implemented in http://elinux.org/Android_Power_Management (as well as kernel drama). Some other links:

https://groups.google.com/group/android-kernel/browse_thread/thread/ee356c298276ad00/472613d15af746ea?lnk=raot&pli=1

http://www.ok-labs.com/blog/entry/context-switching-in-context/

I'm sure that you can find more links of this nature. Since both projects are open source, you can grab the kernel code, and probably get further information from people who actually know what they are talking about in forms and groups.

At the driver level, you need to make sure that your drivers can properly handle suspend and shut devices off that are not in use. Most devices aimed at the mobile market offer very fine-grained support to turn individual components off, and to tweak clock settings (remember, power is proportional to clock^2).

Hope this helps.

Answer 2

You can do quite a bit of power-saving without requiring any special support from the OS, assuming you are writing (or at least have the source code for) your application and drivers.

Your drivers need to be able to disable their associated devices and bring them back up without requiring a restart or introducing system instability. If your devices are connected to a PCI/PCIe bus, research which power states they support (D0 - D3) and what your driver needs to do to transition between these low-power modes. If you are selecting hardware devices to use, look for devices that adhere to the PCI Power Management Specification or have similar functionality (such as a sleep mode and a "wake up" interrupt signal).

When your device boots up, every device that has the ability to detect whether it is connected to anything needs to do so. If any ports or buses detect that they are not being used, power them down or put them to sleep. A port running at full power but sitting unused can waste more power than you might think it would. Depending on your particular hardware and use case, it might also be useful to have a background app that monitors device usage, identifies unused/idle resources, and acts appropriately (like a "screen saver" for your hardware).

Your application software should make sure to detect whether hardware devices are powered up before attempting to use them. If you need to access a device that might be placed in a low-power mode, your application needs to be able to handle a potentially lengthy delay in waiting for the device to wake up and respond. Your applications should also be considerate of a device's need to sleep. If you need to send a series of commands to a hardware device, try to buffer them up and send them out all at once instead of spacing them out and requiring multiple wakeup->send->sleep cycles.

Don't be afraid to under-clock your system components slightly. Besides saving power, this can help them run cooler (which requires less power for cooling). I have seen some designs that use a CPU that is more powerful than necessary by a decent margin, which is then under-clocked by as much as 40% (bringing the performance down to the original level but at a fraction of the power cost). Also, don't be afraid to spend power to save power. That is, don't be afraid to use CPU time monitoring hardware devices for opportunities to disable/hibernate them (even if it will cause your CPU to use a bit more power). Most of the time, this tradeoff results in a net power savings.