3,260
edits
Changes
m
Entering standby Standby mode can be done activated by any userspace application, while wakeup is allowed triggered only from:
→Standby Support
== 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.
* 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 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 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:
