STR Time consuming Guide¶

1. Introduction to STR¶

STR stands for "Suspend to RAM".

Working principle: During system sleep, non-core components such as the CPU and peripherals are powered off, while the memory remains powered.

Core purpose: To minimize power consumption while ensuring that the operating state (such as open programs and data) is not lost.

1.1 STR Process Analysis¶

1.2 Overview of STR Stages¶

This section only introduces the suspend process; the resume process is the opposite.

Switch to suspend console:

This is mainly to ensure that key information from the system can still be captured and viewed during the sleep process (device drivers, system).
PM_SUSPEND_PREPARE Notification

Notifies all registered device drivers to prepare for sleep. Device drivers can respond to this notification by implementing the appropriate callback functions to perform necessary state saving, resource release, and other operations, ensuring that the device can safely enter sleep mode.
Device Suspend

Iterates through the list of all registered devices in the system and calls their corresponding suspend methods.
Disable Secondary CPUs

Powers down non-primary CPUs.
Arch Suspend Disable IRQs

Disables global interrupts. This prevents new interrupts from being triggered and waits for currently processing interrupts to complete.
Syscore Suspend

Calls the suspend callback functions for all drivers or modules registered with the syscore framework.
PM Wakeup Pending

Monitors whether any wake-up events have occurred and aborts the sleep process if necessary.
Suspend Ops Enter

Enters the suspend state and waits for wake-up.

The STR time is the period when the SOC is powered while taking 1 second or more per frame. This time can indirectly reflect power consumption. To quickly locate the duration of each stage of STR, the following debugging methods are provided.

STR time can indirectly reflect power consumption. In order to quickly locate the time consumption of each stage of STR, the following debugging methods are provided.

2.Usage¶

2.1 Step¶

step 1：Open the pm_stage_profiler.

step 2：Run the STR application.

step 3：cat kmsg, View the time consumption information of pm_dage_defiler in kmsg. (Refer to the example of kmsg information in section 2.3)

# open pm_stage_profiler
echo 1 > /sys/devices/virtual/sstar/msys/pm_stage_profiler
# close pm_stage_profiler
echo 0 > /sys/devices/virtual/sstar/msys/pm_stage_profiler

2.2 Method of calculation¶

period	method	description
IPL	IPL Total cost	IPL time consuming
resume	mi_post_suspend_end+ - resume+	Resume time consuming
APP alive	mi_suspend_start+ - mi_post_suspend_end+	APP alive time
suspend	suspend mem - mi_suspend_start+	Suspend to actual sleep time of hardware
exposure	vif framestart - vif resume	The exposure time is from vif resume to vif framestart
Time to make a frame in VIF	vif frameend - vif framestart

2.3 Example¶

Taking single sensor realtime as an example:

2.3.1 Scene¶

2.3.2 kmsg information¶

2.3.3 Time consuming¶

The time required for hardware IO to power on and off can be measured by LA to determine the overall alive time, and then subtracted from the time of "IPL + Resume + APP + Suspend"

IPL:"IPL Total cost" = 6335 us

Resume: "mi_post_suspend_end+ time" - "resume+ time" = 31033 - 15888 = 15145 us

APP: "mi_suspend_start+ time" - "mi_post_suspend_end+ time" = 84260 - 31033 = 53227 us

Suspend: "PM_SUSPEND_MEM time" - "mi_suspend_start+ time" = 98987 - 84260 = 14727 us

Exposure:"mi_vif_framestart+ time" - "mi_vif_resume+ Dev0 time" = 48082 - 34569 = 13513 us

Time to make a frame in VIF:"mi_vif_frameend+ time" - "mi_vif_framestart+ time" = 80761 - 48082 = 32679 us