For enterprise equipment that translates to lower energy costs, while for portable devices that normally means operating for longer on a single charge.
Expectations in this direction have been fuelled by Moore’s Law; every two years we manage to integrate twice as many transistors in the same physical space, leading to greater functionality. As silicon is typically priced by the mm2 and not the transistor, that also means more ‘bang for your buck’. However, Moore’s Law didn’t foresee the impact that power density would have on that continued integration, so that now power management is much more important in integrated devices.
Continually increasing integration also means that many of today’s products are based on a single device; a System-on-Chip. Within these devices there are many functions working co-dependently, which has also given rise to the need for more sophisticated power management.
Empowering your power management
Modern devices, from large SOCs and highly integrated microcontrollers are architected to partition functions into domains, from a voltage, clock and power point of view. This allows for hardware blocks that aren’t being used to be put into a lower power mode, achieved in a number of ways, including clock gating, frequency and/or voltage scaling, or compete isolation from power rails.
Low power modes are controlled through close collaboration between the hardware and software. Often, in a bid to avoid unwanted operation, power saving modes may only be entered under specific conditions and, once entered, may have strict conditions for exiting. This needs to be managed in software, but it isn’t always simple to achieve.
Many SOCs now run a derivative of Linux, or perhaps a commercial operating system such as Windows Embedded, which now have support for power management ‘built in’. For instance, (most) Linux distributions now include frameworks that allow application software to control or request entry/exit to/from low power modes by issuing commands to hardware through the frameworks using APIs, such as pm_runtime and clk_.
These APIs are typically implemented in device drivers; software written to control and access the specific hardware functions of the SOC. As a result, devices drivers will be device-specific and so must be written (normally by the SOC manufacturer) to support the Linux frameworks including as part of the kernel.
In theory, this should ensure that products based on any SOC should be able to achieve the lowest possible operating power profile. In practice, however, it isn’t always that straightforward. The number of device drivers needed for an SOC will vary, depending on the functions the manufacturer has integrated. The quality of those device drivers may also vary; for common features integrated in a number of SOCs the device drivers are likely to be mature and full-featured, for new or rarely integrated functions the device drivers may be less mature, they may not even be available.
This has several implications. Power/clock/voltage domains tend to cover a number of functions, each of which will need its own device driver. If one of the device drivers for a domain is unable to tell the system that its functions are able to