Power Management Device Latencies Measurement
From OMAPpedia
(Difference between revisions)
| Line 222: | Line 222: | ||
|- | |- | ||
|HW total wake-up latency: from wake-up event till WFI exit | |HW total wake-up latency: from wake-up event till WFI exit | ||
| - | |8479 | + | |8479* |
| - | |8749 | + | |8749* |
|OK for RET since no MPU restore code is needed. OFF mode: it is assumed this contains the MPU context restore code | |OK for RET since no MPU restore code is needed. OFF mode: it is assumed this contains the MPU context restore code | ||
|- | |- | ||
|} | |} | ||
| - | + | <nowiki>*</nowiki>: The value of PRM_CLKSETUP (and VOLTSETUP possibly) need some optimization. A value of 0xFF for CLKSETUP means a clock stabilization time of 8ms while it is recommended to have 5.25ms. | |
===Full RET mode=== | ===Full RET mode=== | ||
| Line 260: | Line 260: | ||
* Early resume of devices: 0.488 ms | * Early resume of devices: 0.488 ms | ||
* Resume of devices: 429.962 msecs | * Resume of devices: 429.962 msecs | ||
| + | |||
| + | ==Timings results== | ||
| + | Device constraint code patches, derived from the timings results. | ||
==Attachments== | ==Attachments== | ||
Revision as of 17:11, 8 November 2010
Contents |
PM Devices constraintes measurements
Introduction
To correctly implement the device latency constraint support it is needed to get accurate measurements of the system low power modes overhead:
- Total amount of time taken for a device to become accessible, and so the time for the device to wake-up from a given low power mode.
- It includes turning the clocks on, bringing the clockdomain out of inactive, power domain out of RET or OFF (with context restore) state.
- This constraint mainly governs the deepest device idle state (only clocks cut, clockdomain in inactive, Powerdomain in RET or off) acceptable to the device at any given time.
This wiki page details the measurements setup and the results. The latency data is to be fed into the constraints latency patches.
Kernel patches & build
Some kernel changes are required for the kernel instrumentation. The patches and config are attached to this page
- Starting point: linux-omap master branch at commit a83d12a47c9a8c78a184910150797045d69a1570: Linux-omap rebuilt: Updated to v2.6.36, add 24xx uart fix
- khilman's patch to fix the low power mode: 1e91c5f70da4d7d108cbcf026164d001e0e688b3: OMAP: bus-level PM: enable use of runtime PM API for suspend/resume
- Tracing instrumentation patches
- 2ae0c90dc76c7b96c192be1a6b7180016ecafc57 tracing, perf: add more power related events
- e44b2e1cdf19039771e02b3f1a021f9c3c43cf68 perf: add suspend tracepoint calls
- 2e7387e37300f490de6a29c231bf61849f0a8a2e OMAP3: clean up ASM idle code
- e7eeedd4c3a5d102d57d53707b322806cd21365e OMAP3: add low power entry/exit latency trace points
- GPIO instrumentation
- 17f9faf3bc2c3d643a48624779acd90d2d499f2c OMAP3: Add HW tracing code
- Kernel config for Beagleboard
Changes: DSS for Beagle, Initramfs Busybox root FS
HW traces details
The trace points are connected on Beagleboard rev B7.
- Trace A: on the USER button, at the connection to R36. This signal is the system wake-up event. The trigger is set on the raising edge of the signal.
- Trace B: USR1 LED (GPIO_149). This signal is set at the end of omap_sram_idle, along with trace_power_start(POWER_WAKEN, 7, smp_processor_id());. This allows to synchronize the time between the HW and the SW traces.
Because of the difficulty to add trace code for HW/SW tracing in the early wake-up code path, the MPU context restore code in ASM (triggered by the ROM code) is considered as part of the HW wake-up sequence. This code path is executed for OFF mode only.
!Warning! The HW power supplies and external clocks are not cut off in this config (no support for System OFF in l-o), so the HW latencies are lower than expected. The measurements from TI are used for the real HW latency.
Here are some scope screenshots showing the time delta between the wake-up event (USER button press, trace A) and the end of omap_sram_idle (USR1 Led).
For RET mode, showing a delta of 408us:
For OFF mode, showing a delta of 2700us:
SW trace usage
Enable the power events and dump the trace:
# echo 1 > /debug/tracing/events/power/enable # cat /debug/tracing/trace_pipe &
Trigger the suspend, RET mode:
# echo 0 > /debug/pm_debug/enable_off_mode
# echo mem > /sys/power/state
[ 3966.216278] PM: Syncing filesystems ... done.
[ 3966.221557] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 3966.249267] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 3966.281188] Suspending console(s) (use no_console_suspend to debug)
[ 3966.404327] PM: suspend of devices complete after 112.426 msecs
[ 3966.406127] PM: late suspend of devices complete after 1.739 msecs
[ 3966.406158] Disabling non-boot CPUs ...
[ 3967.267150] Successfully put all powerdomains to target state
[ 3967.267791] PM: early resume of devices complete after 0.396 msecs
[ 3967.686279] PM: resume of devices complete after 418.243 msecs
[ 3967.726715] Restarting tasks ... done.
sh-503 [000] 3966.406433: power_start: type=3 state=3 cpu_id=0 => Enter suspend
sh-503 [000] 3966.406494: power_start: type=4 state=1 cpu_id=0 => First suspend trace point in omap_sram_idle
sh-503 [000] 3966.406525: power_start: type=4 state=2 cpu_id=0 => ...
sh-503 [000] 3966.406555: power_start: type=4 state=3 cpu_id=0
sh-503 [000] 3966.406586: power_start: type=4 state=4 cpu_id=0
sh-503 [000] 3966.406616: power_start: type=4 state=5 cpu_id=0
sh-503 [000] 3966.406647: power_start: type=4 state=6 cpu_id=0
sh-503 [000] 3966.406647: power_start: type=4 state=7 cpu_id=0
sh-503 [000] 3966.406647: power_start: type=4 state=8 cpu_id=0 => Last trace for low power enter, just before WFI
sh-503 [000] 3967.266937: power_start: type=5 state=1 cpu_id=0 => First wake-up trace point, at return from omap34xx_save_cpu_context_wfi
sh-503 [000] 3967.266937: power_start: type=5 state=2 cpu_id=0 => ...
sh-503 [000] 3967.266937: power_start: type=5 state=3 cpu_id=0
sh-503 [000] 3967.266937: power_start: type=5 state=4 cpu_id=0
sh-503 [000] 3967.267029: power_start: type=5 state=5 cpu_id=0
sh-503 [000] 3967.267059: power_start: type=5 state=6 cpu_id=0
sh-503 [000] 3967.267120: power_start: type=5 state=7 cpu_id=0 => Last wake-up trace point, at the end of omap_sram_idle
sh-503 [000] 3967.267181: power_start: type=3 state=0 cpu_id=0 => Exit suspend
With OFF mode enabled:
# echo 1 > /debug/pm_debug/enable_off_mode
# echo mem > /sys/power/state
[ 1898.722778] PM: Syncing filesystems ... done.
[ 1898.728057] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 1898.755950] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 1898.787872] Suspending console(s) (use no_console_suspend to debug)
[ 1898.910980] PM: suspend of devices complete after 112.396 msecs
[ 1898.912780] PM: late suspend of devices complete after 1.739 msecs
[ 1898.912811] Disabling non-boot CPUs ...
[ 1900.083923] Successfully put all powerdomains to target state
[ 1900.084686] PM: early resume of devices complete after 0.488 msecs
[ 1900.514953] PM: resume of devices complete after 429.962 msecs
[ 1900.555725] Restarting tasks ... done.
sh-503 [000] 1898.913086: power_start: type=3 state=3 cpu_id=0 => Enter suspend
sh-503 [000] 1898.913147: power_start: type=4 state=1 cpu_id=0 => First suspend trace point in omap_sram_idle
sh-503 [000] 1898.913147: power_start: type=4 state=2 cpu_id=0 => ...
sh-503 [000] 1898.913208: power_start: type=4 state=3 cpu_id=0
sh-503 [000] 1898.913239: power_start: type=4 state=4 cpu_id=0
sh-503 [000] 1898.913269: power_start: type=4 state=5 cpu_id=0
sh-503 [000] 1898.913391: power_start: type=4 state=6 cpu_id=0
sh-503 [000] 1898.913391: power_start: type=4 state=7 cpu_id=0
sh-503 [000] 1898.914337: power_start: type=4 state=8 cpu_id=0 => Last trace for low power enter, just before WFI
sh-503 [000] 1900.083405: power_start: type=5 state=1 cpu_id=0 => First wake-up trace point, at return from omap34xx_save_cpu_context_wfi
sh-503 [000] 1900.083466: power_start: type=5 state=2 cpu_id=0 => ...
sh-503 [000] 1900.083496: power_start: type=5 state=3 cpu_id=0
sh-503 [000] 1900.083588: power_start: type=5 state=4 cpu_id=0
sh-503 [000] 1900.083771: power_start: type=5 state=5 cpu_id=0
sh-503 [000] 1900.083801: power_start: type=5 state=6 cpu_id=0
sh-503 [000] 1900.083862: power_start: type=5 state=7 cpu_id=0 => Last wake-up trace point, at the end of omap_sram_idle
sh-503 [000] 1900.083954: power_start: type=3 state=0 cpu_id=0 => Exit suspend
Timings results
Results interpretation
The low power transition sequence is pictured as nested calls to functions:
The measured results (from the HW and SW traces) are mapped to the picutrede states according to the following table:
| Picured state | Trace point |
|---|---|
| Idle enter | start suspend |
| omap_sram_idle 1 | suspend trace point 1 |
| omap_sram_idle 2 | suspend trace point 2 |
| omap_sram_idle 3 | suspend trace point 3 |
| omap_sram_idle 4 | suspend trace point 4 |
| omap_sram_idle 5 | suspend trace point 5 |
| omap_sram_idle 6 | suspend trace point 6 |
| omap_sram_idle 7 | suspend trace point 7 |
| WFI enter | suspend trace point 8 |
| System OFF active | - sys_off_mode signal to be measured with System OFF support |
| Wake-up event | HW trace A |
| System OFF inactive | - sys_off_mode signal to be measured with System OFF support |
| WFI exit | -* |
| omap_sram_idle 1 | wake-up trace point 1* |
| omap_sram_idle 2 | wake-up trace point 2 |
| omap_sram_idle 3 | wake-up trace point 3 |
| omap_sram_idle 4 | wake-up trace point 4 |
| omap_sram_idle 5 | wake-up trace point 5 |
| omap_sram_idle 6 | wake-up trace point 6 |
| omap_sram_idle 7 | wake-up trace point 7, HW trace B |
| Idle exit |
*: Because of the difficulty to add trace code for HW/SW tracing in the early wake-up code path, the MPU context restore code in ASM (triggered by the ROM code) is considered as part of the HW wake-up sequence. This code path is executed for OFF mode only.
Some timings measurements have been made at chip characterization. The timings for the HW part of the sequence are taken from those results. The following table gives the results:
| Characterization measurement | Full RET (us) | Full OFF (us) | Remark |
|---|---|---|---|
| HW sleep latency: from WFI enter till sys_off_mode active | 154 | - | Not measured in OFF mode, to be done once System OFF support is in l-o |
| HW total sleep latency: from WFI enter till System OFF (voltages and external clocks cut off) | 494 | 3784 | |
| HW wake-up latency: from sys_off_mode inactive till WFI exit | 245 | - | Not measured in OFF mode. The MPU context restore code is considered as part of the HW restore |
| HW total wake-up latency: from wake-up event till WFI exit | 8479* | 8749* | OK for RET since no MPU restore code is needed. OFF mode: it is assumed this contains the MPU context restore code |
*: The value of PRM_CLKSETUP (and VOLTSETUP possibly) need some optimization. A value of 0xFF for CLKSETUP means a clock stabilization time of 8ms while it is recommended to have 5.25ms.
Full RET mode
- Suspend of devices: 112.426 ms
- Late suspend of devices: 1.739 ms
- From suspend start till omap_sram_idle entry: 61us
- From omap_sram_idle entry till WFI: 153us
- ... HW sleep... including MPU context restore in ASM
- From WKUP event (USER button) till return from omap34xx_save_cpu_context_wfi: 194us
- From return from omap34xx_save_cpu_context_wfi till end of omap_sram_idle: 214us
- From end of omap_sram_idle till return from suspend: 30us
- Early resume of devices: 0.396 ms
- Resume of devices: 418.243 msecs
Full OFF mode
- Suspend of devices: 112.396 ms
- Late suspend of devices: 1.739 ms
- From suspend start till omap_sram_idle entry: 61us
- From omap_sram_idle entry till WFI: 1190us
- ... HW sleep... including MPU context restore in ASM
- From WKUP event (USER button) till return from omap34xx_save_cpu_context_wfi: 2151us
- From return from omap34xx_save_cpu_context_wfi till end of omap_sram_idle: 457us
- From end of omap_sram_idle till return from suspend: 92us
- Early resume of devices: 0.488 ms
- Resume of devices: 429.962 msecs
Timings results
Device constraint code patches, derived from the timings results.
Attachments
Kernel patches and config
File:OMAP latency measurements patches and config.tar.gz
--Jpihet 14:21, 5 November 2010 (UTC)
