Changes

Jump to: navigation, search

NELK Power Management

158 bytes added, 11:36, 14 January 2014
m
no edit summary
{{InfoBoxTop}}
{{AppliesToNaonFamily}}
{{InfoBoxBottom}}
 
== Introduction ==
In this article we'll see how Power Management is implemented in [[Naon Embedded Linux Kit (NELK)|NELK]], which option is available to the user and which result, related to power consumption, can be reached.
The situation is even harder to manage because of internal system constraint: changing the frequency for a subsystem requires changing its power supply (as a rule of thumb, higher power supply is required to have a stable higher frequency). There are some other restrictions that do not allow the user to select arbitrary settings on different subsystems (which would lead to system instability).
For its [[:Category:Naon|Naon]] platform, Dave '''DAVE Embeddded Systems''' provides a ''custom'' PM driver that allows for selection, at runtime, of an OPP for each subsystem (Cortex A8, CORE, DSP, HDVICP) providing a default stable voltage/frequency setting. Some OPPs are directly derived from the ones officially supported by TI (see DM814x TRM at DVFS section, for example) and some other custom OPPs are provided by Dave'''DAVE Embeddded Systems'''.
{| class="wikitable"
== Standby Support ==
Entering standby means putting the [[Category:Naon|Naon]] module in into a ''sleep'' state, where the power consumption is minimal and also no processing is allowed. All processes are halted, ARM Cortex A8 goes into a specific mode called WFI (''Wait For Interrupt'') and DDR2 RAM goes in into self-refresh mode (the lowest power consumption mode without wasting memory contents).
An introduction to Standby support on DM814x SOC can be found on [http://processors.wiki.ti.com/index.php/DM814x_AM387x_PM_Suspend_resume_overview TI wiki] too.
Entering standby Standby mode can be done activated by any userspace application, while wakeup is allowed triggered only from:
* internal timer (which, of course, should be enabled and configured before entering standby)
* an interrupt sources source (e.geg. GPIO or UART). Please note that having an interrupt source enabled means that its clocks cannot be disabled when entering standby mode.
By default timer and UART (Linux serial console) wakeup are enabled.
{{Board Specific Information|text=To allow UART wakeup from Linux console, the user should add '''no_console_suspend''' parameter to kernel command line. See [[Change Linux Command Line Parameter from U-boot]] for more information on how to do this.}}
Due to system complexity and user application dependency, standby mode requires a bit of configuration for optimal performance. The user can (and should) set the standby configuration for various clockclocks, depending on it's its application. However Dave '''DAVE Embeddded Systems''' provides a default clock configuration and system setup that usually is both functional and best performing for common [[Category:Naon|Naon]] based platform. Clock Clocks are managed by the same Naon PM driver described on the previous sections.
From the '''user point of view''', entering standby is a matter of:
# configuring suspend/standby clock clocks (by slowing down their frequencies and/or gate gating them completely)
# configure wakeup sources
# enter standby
The first step is the most complex one, but is required to have obtain the best performance regarding performances in relation to power consumption. Dave '''DAVE Embeddded Systems''' provides a script that correctly configure configures most of the unused clock clocks and give gives the best power result, without too much impact on suspend/wakeup performance (regarding in terms of suspend/wakeup latency).
Here is the bash script provided with NELK:
<pre>
</pre>
See also the following table to understand what is done on each subsystem:
{| class="wikitable"
|}
Configuring wakeup source sources is a matter of choosing which IRQ are left unmasked when entering standby and isenabling/how enable configuring wakeup timer. We will take a look only to consider the latter, because the former is highly driver dependent.
Wakeup timer is described in details into in the [http://processors.wiki.ti.com/index.php/DM814x_AM387x_PM_Suspend_resume_overview TI wiki]. In brief, the user should just enter the timeout (in seconds and/or milliseconds) via sysfs. E.gEg. to wakeup after 2.5 secs seconds standby mode is entered, the following command can be used:
<pre class="board-terminal">
</pre>
{{Board Specific Information|text=Please note that the above commands requires require debugfs enabled and mounted (e.geg. ''mount -t debugfs debugfs /sys/kernel/debug'')}}
After all the above stuff has been setup, user can go into standby by running the following command
</pre>
If wakeup timer has been configured, among amongst the other messages , the user will see something like the following:
<pre class="board-terminal">
From the '''kernel point of view''' entering stand-by means:
* syncing filesystems and freezing processes
* call suspend() function of each registered device driver (e.geg. suspend() function of USB driver will put usb phy in suspend too)
* saving current OPP and entering OPP0 (see above)
* reconfigure and/or gate the user defined clocks
* (if needed) configure wakeup timer
* (if needed) mask all interrupts apart from except for the peripheral peripherals used for wakeup
* put DDR in self refresh
* put Cortex A8 in WFI
When an interrupt is issue issued or when wakeup timer elapses:
* Cortex A8 goes out of WFI
* DDR RAM are put back in working mode
* interrupt mask masks are restored
* the previously saved OPP is restored
* clock clocks are un-gated and/or restored* all processes are unfreezedunfrozen
=== Evaluate Wakeup Latency ===
* the wakeup latency is the running time of ''echo mem'' command minus the wakeup timer configuration.
This is not very precise but give gives an order of magnitude measure of the latency. Please note that the time for entering standby is also taken in into account.
Here is a sample result:
== PM performance and power consumption summary ==
In the following table we summarize the power consumption of the whole [[Category:Naon|Naon]] module (3.3V power supply) in the different situations.
{| class="wikitable"
* in standby mode on module 10/100Mbit Ethernet Phy is kept in reset
* 0% on both ''Processing'' columns means that the subsystem is turned on but without input
* shut shunt voltage has been measured on R422 (10mOhm), in [[:Category:NaonEVB-Mid|NaonEVB-Mid]], which feeds [[:Category:Naon|Naon]] module 3.3V power supply
== Tools ==

Navigation menu