Documentation/Maemo 5 Developer Guide/Architecture/System Software

(→Device State Management Entity (DSME))
(reformat tables slightly)
 
(12 intermediate revisions not shown)
Line 1: Line 1:
-
=System Software Architecture=
 
System software architecture is divided into three subsystems:  
System software architecture is divided into three subsystems:  
-
*System Control (SC)
+
* [[#System Control|System Control]] (SC)
-
*Energy Management (EM) and  
+
* [[#Energy Management|Energy Management]] (EM) and  
-
*Power Management (PM).
+
* [[#Power Management|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.
+
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.
+
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 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.
+
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. 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==
==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.  
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.  
Line 19: Line 19:
====Status Bar and Control Panel plugins====
====Status Bar and Control Panel plugins====
 +
This section describes the various UI elements and widgets that are part of the system control subsystem.  
This section describes the various UI elements and widgets that are part of the system control subsystem.  
-
{|cellspacing="0" border="1" width="70%"
+
;Name
-
|'''Name'''||'''Status Bar Battery plugin'''
+
: Status Bar Battery plugin
-
|-
+
;Purpose
-
|'''Purpose'''||Provides battery status settings
+
: Provides battery status settings
-
|-
+
;Description
-
|'''Description||*Provides status bar plugin to visualize battery status <br>* Provides estimation for battery time left  for idle and use scenarios
+
: <ul><li>Provides status bar plugin to visualize battery status</li><li>Provides estimation for battery time left  for idle and use scenarios</li></ul>
-
|}
+
 +
;Name
 +
: Control Panel Display plugin
 +
;Purpose
 +
: Provides display and autolock settings
 +
;Description
 +
: Provides control panel plugin for:<ul><li>display brightness</li><li>brightness period</li><li>switch off period</li><li>screen and key lock when screen goes off</li><li>LED control</li></ul>Store the settings in DSM Gconf
-
{|cellspacing="0" border="1" width="70%"
+
;Name
-
|'''Name'''||'''Control Panel Display plugin'''
+
: Control Panel Device Lock plugin
-
|-
+
;Purpose
-
|'''Purpose'''||Provides display and autolock settings
+
: Provides device lock settings
-
|-
+
;Description
-
|'''Description'''||Provides control panel plugin for <br> *display brightness  <br> *brightness period <br> *switch off period <br> *screen and key lock when screen goes off <br> *LED control <br>Store the settings in DSM Gconf
+
: Provides control panel plugin for<ul><li>autolock settings (on/off, period)</li><li>*lock code</li></ul><br/>Store the settings in DSM Gconf
-
|}
+
 +
===Device State Management Entity (DSME)===
-
{|cellspacing="0" border="1" width="70%"
+
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 a single process. The D-Bus interface provides services to request reboot, shutdown or powerup (from acting dead mode), indication of shutdown, thermal events and data save.
-
|'''Name'''||'''Control Panel Device Lock plugin'''
+
-
|-
+
-
|'''Purpose'''||Provides device lock settings
+
-
|-
+
-
|'''Description'''||Provides control panel plugin for <br>  *autolock settings (on/off, peroid) <br>  *lock code <br>Store the settings in DSM Gconf
+
-
|}
+
-
===Device State Management Entity (DSME)===
+
[[Image:DSME.png|frame|center|alt=Diagram of DSME components|DSME components]]
-
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.
+
-
[[Image:DSME.png]] <br>
 
 +
{{ambox
 +
|text=In Fremantle release onwards, DSME is not part of the initfs anymore. Instead, it is located in the rootfs and started after init.}}
-
''Note: In Fremantle release onwards, DSME is not part of the initfs anymore. Instead, it is located in the rootfs and started after init.''
+
;Name
 +
: Device State Management Entity
 +
;Purpose
 +
: Provides device state control logic and management interface.
 +
;Description
 +
: <ul><li>Provides means for configuration and management interface.</li><li>Provides lifeguard CLI API for system service startup.</li><li>Manages device state including display, watchdog and startup.</li></ul>
-
{|cellspacing="0" border="1" width="70%"
+
===Mode Control Entity (MCE)===
-
|'''Name'''||'''Device State Management Entity'''
+
-
|-
+
-
|'''Purpose'''||Provides device state control logic and management interface.
+
-
|-
+
-
|'''Description'''||*Provides means for configuration and management interface. <br>*Provides lifeguard CLI API for system service startup. <br>*Manages device state including display, watchdog and startup.
+
-
|}
+
-
===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.
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.
-
{|cellspacing="0" border="1" width="70%"
+
;Name
-
|'''Name'''||'''Mode Control Entity'''
+
: Mode Control Entity
-
|-
+
;Purpose
-
|'''Purpose'''||Provides device mode logic and services for DSM interface.
+
: Provides device mode logic and services for DSM interface.
-
|-
+
;Description
-
|'''Description'''||*Provides means for device mode control (Eg: flight mode) <br>*Provides DSM gconf API for controlling display and security. <br>*Manages DSM API for applications.
+
: <ul><li>Provides means for device mode control (Eg: flight mode)</li><li>Provides DSM gconf API for controlling display and security.</li><li>Manages DSM API for applications.</li></ul>
-
|}
+
-
 
+
===Hardware Abstraction Layer (HAL)===
===Hardware Abstraction Layer (HAL)===
-
{|cellspacing="0" border="1" width="70%"
 
-
|'''Name'''||'''Hardware Abstraction Layer'''
 
-
|-
 
-
|'''Purpose'''||Provides hardware abstraction layer for applications.
 
-
|-
 
-
|'''Description'''||*Provides unified API for applications to query device properties and receive events for changes. <br>*Gathers information of devices via various kernel  interfaces (sysfs, udev)
 
-
|}
 
 +
;Purpose
 +
: Provides hardware abstraction layer for applications.
 +
;Description
 +
: <ul><li>Provides unified API for applications to query device properties and receive events for changes.</li><li>Gathers information of devices via various kernel  interfaces (sysfs, udev)</li></ul>
-
===Alarmd===
+
===Alarm Daemon (Alarmd)===
-
{|cellspacing="0" border="1" width="70%"
+
-
|'''Name'''||'''Alarm Daemon'''
+
-
|-
+
-
|'''Purpose'''||Provides centralized place for requesting scheduled events.
+
-
|-
+
-
|'''Description'''||*Provides service and API for requesting, changing and deleting scheduled events.<br>*Uses SystemUI to show dialogs for alarms and calendar events.
+
-
|}
+
 +
;Purpose
 +
: Provides centralized place for requesting scheduled events.
 +
;Description
 +
: <ul><li>Provides service and API for requesting, changing and deleting scheduled events.</li><li>Uses SystemUI to show dialogs for alarms and calendar events.</li>
-
===Clockd===
+
===Time Daemon (Clockd)===
-
{|cellspacing="0" border="1" width="70%"
+
-
|'''Name'''||'''Time Daemon'''
+
-
|-
+
-
|'''Purpose'''||Provides centralized place for handling time.
+
-
|-
+
-
|'''Description'''||*Provides service and API for requesting, changing and notifying time and timezone changes.<br>*Provides interface for monitoring network time notifications.
+
-
|}
+
 +
;Purpose
 +
: Provides centralized place for handling time.
 +
;Description
 +
: <ul><li>Provides service and API for requesting, changing and notifying time and timezone changes.</li><li>Provides interface for monitoring network time notifications.</li>
-
===Profiled===
+
===Profile Daemon (Profiled)===
-
{|cellspacing="0" border="1" width="70%"
+
-
|'''Name'''||'''Profile Daemon'''
+
-
|-
+
-
|'''Purpose'''||Provides centralized place for handling (user) profiles related data and notifications.
+
-
|-
+
-
|'''Description'''||Provides service and API for requesting, changing and notifying profile related data.
+
-
|}
+
 +
;Purpose
 +
: Provides centralized place for handling (user) profiles related data and notifications.
 +
;Description
 +
: Provides service and API for requesting, changing and notifying profile related data.
-
===Heartbeatd===
+
===Heartbeat Daemon (Heartbeatd)===
-
{|cellspacing="0" border="1" width="70%"
+
-
|'''Name'''||'''Heartbeat Daemon'''
+
-
|-
+
-
|'''Purpose'''||Provides service to wake up applications on requested interval, internally groups the wakeups together inorder to save power.
+
-
|-
+
-
|'''Description'''||*Provides service and API for requesting, changing and deleting wakeups on specific intervals.<br>*Uses kernel module to delay TCP keepalives and sends them in bunches.
+
-
|}
+
 +
;Purpose
 +
: Provides service to wake up applications on requested interval, internally groups the wakeups together inorder to save power.
 +
;Description
 +
: <ul><li>Provides service and API for requesting, changing and deleting wakeups on specific intervals.</li><li>Uses kernel module to delay TCP keepalives and sends them in bunches.</li></ul>
===Public Interfaces===
===Public Interfaces===
 +
This section lists the public interfaces provided by the System Control Subsystem.
This section lists the public interfaces provided by the System Control Subsystem.
-
{|cellspacing="0" border="1" width="70%"
+
 
-
|'''Interface'''||'''Purpose'''
+
{| class="wikitable"
 +
|+ System control public interfaces
 +
|-
 +
! Interface !! Purpose !! Interface type
|-
|-
-
|DSME API||Interface for requesting device powerup, shutdown and reboot. <br>Interface for thermal management indications. <br>Type: D-Bus  
+
| DSME API || Interface for requesting device powerup, shutdown and reboot. <br/>Interface for thermal management indications.
 +
| D-Bus
|-
|-
-
|Dsmetool CLI||Interface for init scripts to start processes which will be monitored  
+
| Dsmetool CLI || Interface for init scripts to start processes which will be monitored for system robustness.
-
for system robustness. <br>Type: Socket  
+
| Socket
|-
|-
-
|HAL API||Provides device property information and events about device state changes. <br>
+
| HAL API || Provides device property information and events about device state changes.
-
Type: 1) D-Bus or 2) library (libhal)  
+
| D-Bus or library (libhal)
|-
|-
-
|DSM gconf API||Interface for DSM related configuration values (security lock key, display)  
+
| DSM GConf API || Interface for DSM related configuration values (security lock key, display)
 +
| GConf
|-
|-
-
|MCE API||Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status. <br>
+
| MCE API || Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status.
-
Type: D-Bus  
+
| D-Bus  
|-
|-
-
|Profile API||Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status. <br>
+
| Profile API || Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status.
-
Type: D-Bus  
+
| D-Bus  
|-
|-
-
|Time API||Control and notifications about timezone and time changes. <br>
+
| Time API || Control and notifications about timezone and time changes.
-
Type: D-Bus  
+
| D-Bus  
|-
|-
-
|Alarm API||Requesting, changing and deleting alarms.<br>
+
| [[Documentation/Maemo 5 Developer Guide/Using Generic Platform Components/Alarm Framework|Alarm API]] || Requesting, changing and deleting alarms.
-
Type: D-Bus  
+
| D-Bus  
|-
|-
-
|HeartBeat API||Getting heart beat on requested interval. <br>
+
| HeartBeat API || Getting heart beat on requested interval.
-
Type: Socket  
+
| Socket  
|}
|}
-
 
==Energy Management==
==Energy Management==
-
===BME===
 
-
{|cellspacing="0" border="1" width="70%"
 
-
|'''Name'''||'''Battery Management'''
 
-
|-
 
-
|'''Purpose'''||Provides batery monitoring and charging service.
 
-
|-
 
-
|'''Description'''||Provides battery indentification, monitoring, charging and BME API. <br>
 
-
TSS interface for A/D converter calibration. <br>
 
-
Emulation libraries for Nokia OS services.
 
-
|}
 
 +
===Battery management entity (BME)===
 +
 +
;Purpose
 +
: Provides battery monitoring and charging service.
 +
;Description
 +
: <ul><li>Provides battery identification, monitoring, charging and BME API.</li><li>TSS interface for A/D converter calibration.</li><li>Emulation libraries for Nokia OS services.</li>
===HAL battery addon===
===HAL battery addon===
-
{|cellspacing="0" border="1" width="70%"
+
;Purpose
-
|'''Name'''||'''HAL Battery addon'''
+
: Provides battery information via HAL.
 +
;Description
 +
: Provides battery status and type information via HAL.
 +
 
 +
===Public Interfaces===
 +
 
 +
{| class="wikitable"
 +
|+ Energy management public interfaces
|-
|-
-
|'''Purpose'''||Provides batery information via HAL.
+
! Interface !! Purpose !! Type
|-
|-
-
|'''Description'''||Provides battery status and type information via HAL.
+
| Battery HAL API || Battery event API. Provides battery and charger status changes.
 +
| HAL/D-Bus
|}
|}
 +
==Power Management==
-
===Pubic Interfaces===
+
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.
-
{|cellspacing="0" border="1" width="70%"
 
-
|'''Interface'''||'''Purpose'''
 
-
|-
 
-
|Battery HAL API||Battery event API. Provides battery and charger status changes. <br>
 
-
Type: HAL/D-Bus
 
-
|}
 
-
 
-
==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 :
The power management  contains the following elements :
*Clock framework including power and clock domain extensions  
*Clock framework including power and clock domain extensions  
Line 202: Line 183:
===Kernel power management===
===Kernel power management===
 +
Kernel power management has several mechanisms to perform power management. The most commonly used in System Software architecture are listed below.  
Kernel power management has several mechanisms to perform power management. The most commonly used in System Software architecture are listed below.  
-
'''Dynamic sleep''' <br>
+
====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.
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''' <br>
+
====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.
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.
===Components and descriptions===
===Components and descriptions===
 +
====Clock Framework====
-
{|cellspacing="0" border="1" width="70%"
+
;Purpose
-
|'''Name'''||'''Clock Framework'''
+
: Provides clock framework for HW clock management.
-
|-
+
;Responsibilities
-
|'''Purpose'''||Provides clock framework for HW clock management.
+
: <ul><li>Provides common means for turning HW clocks on and off.</li><li>Provides HW clock sanity checks and use counts.</li><li>Allows power management to probe HW clocks status.</li><li>Handles also clock and power domains, and wakeup and sleep dependencies.</li></ul>
-
|-
+
-
|'''Responsibilities'''||Provides common means for turning HW clocks on and off. <br>
+
-
Provides HW clock sanity checks and use counts. <br>
+
-
Allows power management to probe HW clocks status. <br>
+
-
Handles also clock and power domains, and wakeup and sleep dependencies.
+
-
|}
+
 +
====CPU Idle====
-
{|cellspacing="0" border="1" width="70%"
+
;Purpose
-
|'''Name'''||'''CPU Idle'''
+
: Provides mechanism for selecting and entering the deepest possible sleep state based on the constraints
-
|-
+
-
|'''Purpose'''||Provides mechanism for selecting and entering the deepest possible sleep state based on the constraints
+
-
|}
+
 +
====CPU Freq====
-
{|cellspacing="0" border="1" width="70%"
+
;Purpose
-
|'''Name'''||'''CPU Freq'''
+
: Provides mechanism for selecting and entering the lowest possible operating point based on the MPU and DSP loads.
-
|-
+
;Responsibilities
-
|'''Purpose'''||Provides mechanism for selecting and entering the lowes possible operating point based on the MPU and DSP loads.
+
:<ul><li> Monitor CPU and DSP load requirements.</li><li>Adjust CPU and DSP frequencies based on load.</li></ul>
-
|-
+
-
|'''Responsibilities'''||Monitor CPU and DSP load requirements. <br>
+
-
Adjust CPU and DSP frequencies based on load.
+
-
|}
+
===Public Interfaces===
===Public Interfaces===
-
 
+
{| class="wikitable"
-
{|cellspacing="0" border="1" width="70%"
+
|+ Power management public interfaces
-
|'''Name'''||'''Description'''
+
|-
|-
-
|CLK API||Clock framework public API.
+
! Name !! Description
|-
|-
-
|Contraints API||Interface for drivers for setting constraints on bandwidth and latency inorder to control the target sleep states.
+
| CLK API || Clock framework public API.
 +
|-
 +
| Contraints API || Interface for drivers for setting constraints on bandwidth and latency to control the target sleep states.
|}
|}
 +
 +
[[Category:Development]]
 +
[[Category:Documentation]]
 +
[[Category:Fremantle]]

Latest revision as of 10:32, 2 March 2011

System software architecture is divided into three subsystems:

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 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. 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.

Contents

[edit] 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.

[edit] System UI

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

[edit] Status Bar and Control Panel plugins

This section describes the various UI elements and widgets that are part of the system control subsystem.

Name
Status Bar Battery plugin
Purpose
Provides battery status settings
Description
  • Provides status bar plugin to visualize battery status
  • Provides estimation for battery time left for idle and use scenarios
Name
Control Panel Display plugin
Purpose
Provides display and autolock settings
Description
Provides control panel plugin for:
  • display brightness
  • brightness period
  • switch off period
  • screen and key lock when screen goes off
  • LED control
Store the settings in DSM Gconf
Name
Control Panel Device Lock plugin
Purpose
Provides device lock settings
Description
Provides control panel plugin for
  • autolock settings (on/off, period)
  • *lock code

Store the settings in DSM Gconf

[edit] 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 a single process. The D-Bus interface provides services to request reboot, shutdown or powerup (from acting dead mode), indication of shutdown, thermal events and data save.

Diagram of DSME components
DSME components


Image:Ambox_notice.png
 In Fremantle release onwards, DSME is not part of the initfs anymore. Instead, it is located in the rootfs and started after init.
Name
Device State Management Entity
Purpose
Provides device state control logic and management interface.
Description
  • Provides means for configuration and management interface.
  • Provides lifeguard CLI API for system service startup.
  • Manages device state including display, watchdog and startup.

[edit] 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.

Name
Mode Control Entity
Purpose
Provides device mode logic and services for DSM interface.
Description
  • Provides means for device mode control (Eg: flight mode)
  • Provides DSM gconf API for controlling display and security.
  • Manages DSM API for applications.

[edit] Hardware Abstraction Layer (HAL)

Purpose
Provides hardware abstraction layer for applications.
Description
  • Provides unified API for applications to query device properties and receive events for changes.
  • Gathers information of devices via various kernel interfaces (sysfs, udev)

[edit] Alarm Daemon (Alarmd)

Purpose
Provides centralized place for requesting scheduled events.
Description
  • Provides service and API for requesting, changing and deleting scheduled events.
  • Uses SystemUI to show dialogs for alarms and calendar events.

[edit] Time Daemon (Clockd)

Purpose
Provides centralized place for handling time.
Description
  • Provides service and API for requesting, changing and notifying time and timezone changes.
  • Provides interface for monitoring network time notifications.

[edit] Profile Daemon (Profiled)

Purpose
Provides centralized place for handling (user) profiles related data and notifications.
Description
Provides service and API for requesting, changing and notifying profile related data.

[edit] Heartbeat Daemon (Heartbeatd)

Purpose
Provides service to wake up applications on requested interval, internally groups the wakeups together inorder to save power.
Description
  • Provides service and API for requesting, changing and deleting wakeups on specific intervals.
  • Uses kernel module to delay TCP keepalives and sends them in bunches.

[edit] Public Interfaces

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

System control public interfaces
Interface Purpose Interface type
DSME API Interface for requesting device powerup, shutdown and reboot.
Interface for thermal management indications. 		D-Bus
Dsmetool CLI Interface for init scripts to start processes which will be monitored for system robustness. Socket
HAL API Provides device property information and events about device state changes. D-Bus or library (libhal)
DSM GConf API Interface for DSM related configuration values (security lock key, display) GConf
MCE API Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status. D-Bus
Profile API Interface for requesting display control and lock status, device mode changes and status, inactivity status, and device lock mode and status. D-Bus
Time API Control and notifications about timezone and time changes. D-Bus
Alarm API Requesting, changing and deleting alarms. D-Bus
HeartBeat API Getting heart beat on requested interval. Socket

[edit] Energy Management

[edit] Battery management entity (BME)

Purpose
Provides battery monitoring and charging service.
Description
  • Provides battery identification, monitoring, charging and BME API.
  • TSS interface for A/D converter calibration.
  • Emulation libraries for Nokia OS services.

[edit] HAL battery addon

Purpose
Provides battery information via HAL.
Description
Provides battery status and type information via HAL.

[edit] Public Interfaces

Energy management public interfaces
Interface Purpose Type
Battery HAL API Battery event API. Provides battery and charger status changes. HAL/D-Bus

[edit] 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)

[edit] Kernel power management

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

[edit] 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.

[edit] 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.

[edit] Components and descriptions

[edit] Clock Framework

Purpose
Provides clock framework for HW clock management.
Responsibilities
  • Provides common means for turning HW clocks on and off.
  • Provides HW clock sanity checks and use counts.
  • Allows power management to probe HW clocks status.
  • Handles also clock and power domains, and wakeup and sleep dependencies.

[edit] CPU Idle

Purpose
Provides mechanism for selecting and entering the deepest possible sleep state based on the constraints

[edit] CPU Freq

Purpose
Provides mechanism for selecting and entering the lowest possible operating point based on the MPU and DSP loads.
Responsibilities
  • Monitor CPU and DSP load requirements.
  • Adjust CPU and DSP frequencies based on load.

[edit] Public Interfaces

Power management public interfaces
Name Description
CLK API Clock framework public API.
Contraints API Interface for drivers for setting constraints on bandwidth and latency to control the target sleep states.
Retrieved from "https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/System_Software"