Managing power in embedded applications using dual operating systems
Specific power targets are defined by operating performance points (OPP), and governors manage how to transition between these OPPs. Recently, the concept of Power Management Quality of Service (PM QoS) was introduced to tie computing resources and capabilities in the hardware with latencies and throughput needs to define the minimum OPP required across platforms.
Going into details of the application programming interface (APIs) and data structure is beyond the scope of this article, but to help clarify work needed, Figure 2 earlier showed how power management is currently implemented for TI’s OMAP-L138 C6-Integra DSP + ARM processor evaluation module (EVM) via the embedded Linux port.
At the application level, power management policies like OPPs can be accessed via the sysfs interface.In the kernel space, the frameworks with their governors and drivers have Linux generic portions as well as platform (SoC)- and boar-specific driver portions that can be customized.
On the DSP/BIOS operating system, power management services are consolidated under the PWRM (power manager) framework. Similar to the Linux side, PWRM abstracts the low-level work needed to gate clocks and clock domains on/off, control DSP sleep modes and coordinate with the internal resources to govern the safe switching between OPPs. PWRM sits on top of the Power Scaling Library (PSCL) and a Power Management Interface (PMI) as in Figure 3 below.
Figure 3: DSP/ BIOS power management framework.
To coordinate between the Linux and DSP/ BIOS environments, a hardware mechanism is needed to communicate. Let’s look again at TI’s OMAP-L138 C6-Integra DSP + ARM processor for an example of an inter-processor communication works.
The inter-processor communication (IPC) hardware mechanism for the OMAPL-138 C6-Integra DSP + ARM processor is very straightforward as shown in Figure 4 below.
At the SoC level, five CHIPINT bits are allocated in the CHIPSIG memory-mapped register (MMR) located in the SYSCFG system configuration module for the signaling between the DSP and ARM.
Figure 4: OMAP-L138 C6-Integra DSP + ARM processor inter-processor communication (IPC) mechanism
Up to four signals can be mapped for the DSP to notify the ARM and two for the ARM to notify the DSP with an additional signal just for the DSP non-maskable interrupt (NMI) event. Note that two bits are common to both the DSP and ARM so that they can be both interrupted at the same time.
This is a useful future for debugging purposes. Writing a “one” to the bit will generate the signal or event. These events are fed to the respective interrupt controller (INTC) to get mapped to the core interrupt inputs.
To pass data between the processors, any of the internal or external memory areas can be used as shared memory area(s). Mutually exclusivity can be controlled using the mutex or semaphore mechanisms provided with the operating system.
The SoC provides a system-level memory protection unit (MPU) that can protect a memory region from being overwritten by internal bus masters like the ARM or DSP cores or the DMAs. This feature can be useful during development to debug the IPC software mechanism or detect ill-behaved programs or memory leaks.
For Linux and DSP/BIOS, the IPC is abstracted by a software component called DSPLink. It consists of several modules to provide DSP control and code loading, buffer passing and control, and message passing and control. On the Linux side, it is a kernel mode driver. On the DSP/ BIOS side, it is a regular driver that can be called at the task level.
For applications that use the DSP as an accelerator, DSPLink PROC functions can be used to shutdown the DSP if the application no longer needs its service.
This is adequate for most embedded systems where the ARM is running Linux as the master processor and it’s time to disable I/Os and accelerators to go standby. Disabling the DSP will enable more than 91 percent power savings just on the processor alone, as shown in Figure 5 below.
For other states of DSP idle, power savings can be realized by expanding the Linux kernel space platform drivers or creating a user space proxy that uses DSPLink as the message transport to communicate with the DSP/ BIOS side application to send request to PWRM.
Figure 5: Up to 90 percent power reduction can be achieved with existing PM services
For example, to get to an OPP that only idles the DSP (90 percent power savings), add a service to the Linux suspend framework driver that will send a message to the DSP to initiate a PWRM_sleepDSP operation.
Conclusion
With power management services becoming available in mainline Linux kernel, it is possible to achieve substantial power savings by just “turning them on.” I hope that this article will encourage you to look into the hardware features of your platform to see if it is capable of reducing operating power to embrace the “go green” initiative.
Loc Truong is a technologist and a senior member of Texas Instruments’ C6000 digital signal processor (DSP) technical staff. He is currently leading an effort to identify system solutions for TI’s portfolio of high-performance single-core, multicore and open source C6000 DSPs.
Truong has long been involved with embedded microprocessor- and DSP-based system design. His past experience includes sales and marketing applications management as well as development engineering management. Truong has also authored and presented many papers related to embedded systems design, signal processing as well as embedded Linux and multicore programming. He is the holder of several US patents.
Loading comments... Write a comment