Policy Plays Important Role in Intel XScale® Technology Power Management

Developing a policy manager for Windows Mobile devices helps to extend battery life and more.

By Fred Kunz

Today’s smartphones have more power demands than ever before. Some people use these devices in place of portable media players, while others want to be able to play video games or take pictures. Even more people need to be able to keep up with e-mail and read involved attachments. Despite all of that functionality, however, the device still needs to be able to fit in a back pocket and have enough battery life to make and accept phone calls at any time. It’s a smartphone, after all.

Microsoft requires the smartphones using its Windows Mobile operating system to be efficient enough to run in standby mode for 150 hrs. on a single battery charge. That goal is certainly challenging. Yet those needs can certainly be met with Microsoft’s power-management features, the capabilities of the Intel PXA270 processor, and some clever engineering. Doing so won’t even require taking away any games.

The Intel PXA270 processor can be managed through a software framework that permits changes to the speed and thus the power consumption of the processor. Only the power that’s needed is used for any given task. Without the features in the Intel XScale® microarchitecture and a policy manager that interacts with various peripheral-device drivers while managing workload, power management was like a regular light switch. The device was either running at full power or idling. Now, there’s a “dimmer switch” for that management.

The Intel PXA27X processor family provides several operating and low-power modes:

  • Normal
  • Idle: Clocks to the CPU are disabled; Recovery is through interrupt assertion.
  • Deep Idle: Core frequency is 13 MHz.
  • Standby: All power domains except the real-time clock and on-board oscillator are placed in a low-power mode. The state is retained, but no activity is allowed.
  • Sleep: All power domains except the real-time clock (VCC_RTC) and on-board oscillator (VCC_OSC) can be powered off. Recovery is through external and selected internal wake-up events. It requires a system reboot.
  • Deep Sleep: All power domains are powered directly from the backup battery pin.
Putting the device into suspend certainly saves power. But the user still has to be able to use the device. A key element of power management is taking advantage of the lower-power modes of the Intel PXA270 processor whenever the opportunity arises (see Figure 1). If the user is reading e-mail, for example, he or she may only use a tiny fraction of the processor’s capacity. Obviously, nothing could be done that would turn off the screen. But the processor can be put in a low-power idle mode while the user is reading. Power will then be conserved, and the user won’t even be aware that anything occurred. A significant amount of power can be saved by taking advantage of the extended periods of times when the device is in use, but no work is being sent to the processor.

Even when the processor is running in normal mode, power can be saved. This is where the dimmer comes in. The dynamic frequency and voltage capabilities in the Intel XScale processors allow the processor speed and voltages to be adjusted. Users can therefore get just the speed they need without wasting precious power.

The Windows Mobile operating system takes care of some of the power-management chores by managing the operating system and the power states for the peripherals. Yet even more power can be saved by taking advantage of the processor’s numerous power modes. Achieving this goal requires the development of a Policy Manager or the use of a pre-existing one, such as a third-party solution or Intel’s power management technology (see Figure 2). An effective Policy Manager can switch the processor between various frequencies and voltages in normal and idle modes depending on the user’s needs.

When developing a Policy Manager, it’s imperative to begin by thinking about how the device will be used. Will it run memory-intensive applications? Theoretically, the speed of the memory bus can be changed. In practice, however, such a change cannot be done on the fly. Typically, any alteration requires that the device be reset. A user may be willing to go through a soft reset if he or she plans to run a memory-intensive application for an extended period of time. But this isn’t a good option if the user likes to frequently hop back to less demanding tasks. Picking an appropriate memory-bus speed is important. No significant power savings result from changing the memory-bus speed alone. Plus, it doesn’t matter how fast the processor is running if the device is waiting on the memory.

In addition, it’s critical to take into account the needs of the peripherals. If the device relies on speech recognition to wake it from an idle state, for example, the processor probably won’t be able to be slowed to 13 MHz during an idle mode. By the time the device detects the speech and wakes up, it may have missed the most important words.

For these reasons, an effective Policy Manager must give applications and devices a way to communicate their needs. Devices can be engineered with elaborate rules for what functions and peripherals can be turned off in each state to conserve energy. Yet a serious problem arises with this approach: There’s no way to account for every possible scenario. What if a user tries to play games, for example, while he or she is talking on the phone? There will most certainly be users who will try to do such things.


Device drivers and applications are clients of any usable Policy Manager. If the user is viewing the display, for instance, the display must stay on. Caution is required when considering putting a device into a low-power state, such as deep idle, and turning the phase-locked loop (PLL) off when a particular peripheral is needed. A simple way must be found for the Policy Manager to communicate with a device driver. For instance, the Policy Manager could use an activity timer and the display driver could set the activity-timer event when in use.

It’s critical to understand the requirements of the device. In addition, the framework should be utilized to efficiently use the processor without compromising the user’s experience on the device. In theory, having complete control of all of the device drivers and applications would allow for the most efficient use of the processor. Such control is neither reasonable nor practical, however. One also might think that some elaborate communication scheme is needed between peripheral drivers, applications, and the Policy Manager. To realize significant power savings, though, developers must simply know whether or not a peripheral is in use and how much of the CPU’s capacity is being used. Often, the needed information can be obtained without even having to change a third-party driver.

The power modes available in the Intel XScale processor give developers the ability to realize dramatic power savings. They can place the processor in a low-power idle mode when the device is in use while not placing any demands on the processor. An effective Policy Manager looks for and uses all of those opportunities to conserve power.

Don’t overlook the ability to change the processor’s speed during normal operation. For example, say that CPU utilization is quite low. The process to slow down the core can then begin. If utilization is high, it can be sped up. It isn’t necessary to know what the user is doing. Only the demand on the CPU must be known. It’s important, however, to set meaningful thresholds before changing the core speed. Nothing is gained by constantly changing speeds for no reason.

The BSQUARE (www.bsquare.com) Policy Manager has significantly extended battery life for smartphone customers. It also has saved customers money, as they can use smaller batteries in their devices. Because the demands on smartphones are only going to grow, it’s more important than ever to help the devices run as efficiently as possible. Microsoft and Intel have given us a solid foundation to ensure that our customers can work--and play--wherever and whenever they like.

Fred Kunz is a Solutions Architect in the Professional Engineering Services Group at BSQUARE. His specialties include platform-level system software development for ARM, SH, and MIPS processors. Fred holds a MS in Computer Science from the University of Missouri as well as a BS in Computer Science and a BA in Political Science from the University of Utah.