Documentation/Maemo 5 Developer Guide/Architecture/System Software

=System Software Architecture= System software architecture is divided into three subsystems:
 * System Control (SC)
 * Energy Management (EM) and
 * Power Management (PM).

System control subsystem is responsible for device state management (DSME), mode control (MCE) and various UI components including system UI, control panel applets and status bar icons. In addition, the system control subsystem includes HAL component for hardware abstraction, maemo-launcher for application startup execution, alarmd for alarm event handling, clockd for time management, iphbd for synchronization and profiled for profile handling. The SC subsystem provides D-Bus interface towards other applications. All the system control components are located in user space.

Energy management subsystem is responsible of battery charging. More specifically, the EM subsystem handles battery voltage monitoring and recognition, charging (via USB) and charger recognition. In addition, battery plugin for HAL is provided in order to provide standard D-Bus interface towards other applications. For example, the battery applet uses the HAL battery plugin to indicate the battery status in the UI. The EM subsystem components are located both in kernel and user space.

Power management subsystem is located entirely in kernel space. PM subsystem is responsible for putting the OMAP and peripherals into lowest possible power states as often as possible, without compromising performance. In order to achieve this, all the drivers in the system need to co-operate with the PM subsystem. The PM subsystem is build from standard linux kernel components including clock, CPUIdle and CPUFreq frameworks.

System Control
Management of user modes and system states is divided to two separate entities; Mode Control Entity (MCE) and Device State Management Entity (DSME). With this differentiation it is possible to maintain and develop user context and system context control scheme without complex overlaps.

System UI
SystemUI provides services to other components to display UI elements (dialogs, notifications, alarms) that does not have native UI on their own.

Status Bar and Control Panel plugins
This section describes the various UI elements and widgets that are part of the system control subsystem.

Device State Management Entity (DSME)
DSME is responsible of device state management, process lifeguard support, watch dogs and thermal management. DSME architecture is based on modular plugin architecture. DSME core provides message handling capabilities to modules. Each module is dynamically loaded library. DSME runs in single process and is single threaded. The D-Bus interface provides services to request reboot, shutdown or powerup (from acting dead mode), indication of shutdown, thermal events and data save.

￼

''Note: In Fremantle release onwards, DSME is not part of the initfs anymore. Instead, it is located in the rootfs and started after init.''

Mode Control Entity (MCE)
MCE is responsible of handling display control (active/dim/blank), activity monitoring (keys, buttons), keyboard backlight, ambient light sensor (ALS), LEDs and device mode control. In addition, MCE is responsible for providing interface to proximity, accelometer and vibra devices.

Public Interfaces
This section lists the public interfaces provided by the System Control Subsystem.

Power Management
Power management is part of Linux kernel. Various kernel subsystems and components are used to implement the power management. Some of the components are in mainline Linux while others are ARM/OMAP specific. However, all the components are in some Linux tree and no proprietary subsystems or components are used. The power management contains the following elements :
 * Clock framework including power and clock domain extensions
 * CPU Idle
 * CPU Freq
 * Dynamic tick
 * Idle process
 * OMAP power management routines (PRCM)

Kernel power management
Kernel power management has several mechanisms to perform power management. The most commonly used in System Software architecture are listed below.

Dynamic sleep In Dynamic sleep, the idle task is used to trigger the check if the system can go into power saving mode. That is, every time the idle task is scheduled to run, the dynamic sleep mechanism tries to put the system into deepest possible sleep mode compatible with the constraints that are currently active. CPU Idle framework is used to implement the dynamic sleep functionality.

Dynamic Voltage and Frequency Scaling Dynamic Voltage and Frequency Scaling (DVFS) is the other mechanism to save power. DVFS allows to scale down the SoC’s frequency and voltage at runtime to reduce leakage currents and hence save power. The decision to scale the frequency (and consequently voltage) of the ARM and DSP processors is based on their load, bandwidth and latency constraints. CPU Freq framework is used to implement the DVFS.