Linux Power Management (5) _hibernate and sleep function Introduction "Go"

This article was reproduced from: http://www.wowotech.net/pm_subsystem/std_str_func.html

1. Preface

Hibernate and sleep two features are the core features of Linux Generic pm, and they are designed to be similar: pause and save context--power off the system to conserve power > Recovery System--restore context--continue to use.

In this paper, the kernel to the user space provided by the interface as a breakthrough, the overall two features are introduced, and in the subsequent articles, analysis of their implementation of the logic and execution action.

By the way, although these mechanisms exist for a long time in Linux systems (similar concepts exist in Windows systems), they are not used very often in the scroll, especially on PCs, where most people choose to shut down the system directly. Yincuoyangcha, in many embedded devices, designers will use the sleep mechanism to achieve thermal shutdown function, so as to reduce the boot time.

2. Hibernate and sleep-related terminology grooming

In the "Generic pm basic concept and software architecture" mentioned in the Linux Generic pm related to a number of words, such as Hibernate, Sleep, Suspend, Standby, and so on, it sounds a bit chaotic, So before you introduce Hibernate and sleep, let's start with the relationship between these words.

▆hibernate (hibernation) and sleep are abstractions of Linux power management in the user's perspective and are tangible things that users can see. What they have in common is to keep the system running in the context of the suspend (suspend) system and then run after the system resumes, as if nothing had happened. Their differences are the location of context preservation, the triggering method of system recovery, and the specific implementation mechanism. ▆suspend has two levels of meaning.
One is hibernate and sleep function in the lower level implementation of collectively, refers to the suspended (Suspend) system, depending on the context of the location of the save, can be divided into Suspend to disk (STD, hibernate, the context is saved on the hard disk/disk) and suspend to RAM (STR, a type of sleep, the context is stored in RAM);
The second is the implementation of the sleep function at the code level, expressed as "kernel/power/suspend.c "file. ▆standby, a special case of sleep function, can be translated as "nap". Normal sleep (STR), after processing the context, is determined by the arch-The dependent code resets the CPU to a low-power state (usually sleep). In reality, depending on the need for power and sleep wakeup time, the CPU may offer a variety of low-power states, such as the standby state in addition to sleep, in which the CPU is in light sleep mode, with any
Will immediately wake up. ▆wakeup This is the first time we formally put forward the concept of wakeup. We refer to the recovery system many times, in fact called Wakeup in the kernel. On the surface, wakeup is very simple, whether it is hibernation, sleep or nap, there must be a stimulus to let us back to normal state. But what's complicated is, what kind of stimulation can make us wake up? The animal kingdom, the temperature rally may be the only stimulus that allows animals to wake up from hibernation. And the kick, alarm clock, and other stimuli, you can let us wake from sleep. For naps, any hint of trouble can awaken. In the computer World, hibernation (hibernate) turns off the power of the entire system, so to wake up, only the power button is available. While sleeping, in order to shorten the wakeup time, does not shut down all the power supply, in addition, in order to better user experience, usually will retain some important equipment power supply (such as the keyboard), so that these devices can wake up the system. These deliberately retained devices, which can wake up the system, are collectively known as wake-up sources (Wakeup source). The choice of wakeup source is the focus of PM design work (especially sleep, standby, etc.). 

After the above explanation, for the sake of unification, the Volute will switch the representations from the user's point of view (Hibernate and sleep) to the underlying implementation (STD, STR, and Standby).

3. Software architecture and Module Integration 3.1 software architecture

The software architecture of this part of the kernel can be divided into three levels, such as:

1) API layer, which describes an abstraction layer of the user-space API.

There are two types of APIs here, one for hibernate and sleep two functions (global APIs), including practical functions, test functions, debug functions, etc., available in two forms via Sysfs and Debugfs The other is hibernate-specific (STD APIs), available in two forms via SYSFS and character devices.

2) PM core, the core logic layer of power management, is located in the kernel/power/directory, including the main function (main), STD, Str&standby and auxiliary functions (assistant) and many other sub-modules.

Main function, which is responsible for implementing the logic of global APIs and providing the corresponding API for user space;

STD, including hibernate, snapshot, swap, block_io and other sub-modules, is responsible for implementing the STD function and hardware-independent logic;

Str&stanby, including the suspend and suspend_test two sub-modules, is responsible for implementing functions and hardware-independent logic such as STR, standby, and so on.

3) PM Driver, power management driver layer, involved in architecture-independent drive, architecture-related drivers, device models and various device drivers and other software modules.

3.2 User Space interface

3.2.1/sys/power/state

State is a file in Sysfs, the core interface for generic PM, implemented in "KERNEL/POWER/MAIN.C" to place the system in the specified power state (power mode such as Hibernate, Sleep, Standby, etc.). Different power management functions, at the bottom of the implementation, is to switch between different power state.

Reads the file and returns the power state supported by the current system in the form of a string. In the kernel, there are two types of power state, one is hibernate-related, the name is "Disk", except "Disk", the kernel in "KERNEL/POWER/SUSPEND.C" in the form of an array to define the other 3 state, as follows:

   1:Const Char*ConstPm_states[pm_suspend_max] = {   2: [Pm_suspend_freeze] ="Freeze",   3: [Pm_suspend_standby] ="Standby",   4: [Pm_suspend_mem] ="Mem",   5: };

These power state explanations are as follows:

▆freeze

This power state does not involve specific hardware or driver, but freezes all processes, including user-space processes and kernel threads. Compared with our well-known "hibernation" and "sleep", it is called "Resting Your Eyes" (it can be imagined that the energy savings are limited).

Note: We did not specifically describe the state in the previous description because it was only part of the function of sleep, hibernate, and so on in the earlier kernel, only to be independent in the near future. Another reason is that the state's power-saving effect is not ideal, so its reference scenario is limited. 】

▆standby, the standby state described in the 2nd Chapter.

▆mem, the sleep function that is commonly spoken, is also the str,suspend to RAM described in the 2nd Chapter.

▆disk, Hibernate function, is also the 2nd chapter described in the Std,suspend to disk.

Writing a specific power state string will set the system to that mode.

3.2.2/sys/power/pm_trace

PM Trace is used to provide trace records in the power management process, controlled by the "CONFIG_PM_TRACE" macro definition (Kernel/power/kconfig), and compiled into the kernel, and by the "/sys/power/pm_trace" The file is controlled at run time to enable the feature.

The specific implementation of this feature is "platform-related", which we do not describe here.

3.2.3/sys/power/pm_test

PM test is used to test the power management functionality, and is controlled by the "CONFIG_PM_DEBUG" macro definition (Kernel/power/kconfig) to compile into the kernel. Its core ideas are:

▆ The power management process in sequence, divided into several steps, such as core, platform, devices, etc. These steps are called PM Test level. The ▆ system saves the system's current PM Test level through a global variable (pm_test_level). The value of the variable can be obtained and modified through the "/sys/power/pm_test" file. ▆ at the end of each power management step, insert the PM test code, which takes the current execution step as a parameter, determines whether the current PM Test level and the execution steps are consistent, and if so, the step is executed successfully. For test purposes, after successful execution, the system prints the test information and exits the PM process after waiting for some time. ▆ developers can modify the global test level to see if the steps they are interested in are performing successfully. 

As already mentioned, the file is used to obtain and modify the PM Test level, the specific level information in the "KERNEL/POWER/MAIN.C" definition, the format is as follows (the specific meaning, relatively simple, the relevant code to see, very clear, here is not verbose):

 1:Static Const Char*ConstPm_tests[__test_after_last] = {   2: [Test_none] ="None",   3: [Test_core] ="Core",   4: [Test_cpus] ="Processors",   5: [Test_platform] ="Platform",   6: [Test_devices] ="Devices",   7: [Test_freezer] ="Freezer",   8: };

3.2.4/sys/power/wakeup_count

This interface is only related to the SLEEP function and is therefore controlled by the "CONFIG_PM_SLEEP" macro definition (Kernel/power/kconfig). It exists in order to solve the synchronization problem between sleep and wakeup.

We know that after the system sleeps, the system can be awakened by preserving the wakeup source. In today's CPU system, the wake-up system is the wake-up CPU, and the only way to wake the CPU is Wakeup source interrupt (the kernel is called Wakeup event). and the kernel to ensure that in a variety of states, sleep/wakeup behavior can be normal, as follows:

Eventevent. You should give up entering sleep at this time. This is not so easy to do. For example, when the wakeup event occurs in "event, or is only partially processed." The kernel thinks the event has already been processed, and therefore does not abandon the sleep action. This will cause, after the Wakeup event, the user space program has regretted, do not want to sleep, but eventually sleep down. Until the next wakeup event arrives. 

To solve the above problem, the kernel provides a wkaeup_count mechanism, with "/sys/power/state", to achieve synchronization during sleep. The operating behavior of this mechanism is as follows:

▆wakeup_count is the count that the kernel uses to hold the current wakeup event occurrence. The ▆  User space program reads the Wakeup_count and writes the obtained count back to Wakeup_count before writing to the state switch status. The ▆ kernel will be more consistent than the count of writeback and the current count, and if not, the kernel will return an error if the eventis read. After the ▆ user space program detects a write error, it cannot continue after the action, need to process the response of the event and wait for another read / write back to Wakeup_count. ▆ if the kernel is consistent, the event snapshot is logged when the write Wakeup_count succeeds, and the suspend action is checked to see if it matches the snapshot and terminates suspend if it does not match. After the ▆ user space program detects that the write is correct, you can continue writing to the State to initiate a status switch. And it's safe at this point. 

Scroll will be in the following article, detailed description of the mechanism in the kernel of the implementation of logic, there is no further explanation.

3.2.5/sys/power/disk

This interface is unique to Std. The type used to set or get Std. The types of STD supported by the current kernel include:

 1:Static Const Char*ConstHibernation_modes[] = {   2: [Hibernation_platform] ="Platform",   3: [Hibernation_shutdown] ="shutdown",   4: [Hibernation_reboot] ="reboot",   5: #ifdef config_suspend6: [Hibernation_suspend] ="Suspend",   7:#endif   8: };

▆platform, which means using platform-specific mechanisms to handle STD operations, such as using Hibernation_ops.

▆shutdown, the kernel invokes the Kernel_power_off interface by shutting down the system for Std.

▆reboot, the kernel invokes the Kernel_restart interface by implementing the STD by rebooting the system.

Note: The implementation of the above two kernel_xxx interfaces can be referred to "Generic pm reboot process". 】

▆suspend, the use of STR function to achieve STD. Under this type, the STD and str underlying processing logic is similar.

3.2.6/sys/power/image_size

This interface is also STD-specific. We know that the principle of STD is to keep the current running context in the system disk (such as NAND Flash, such as a hard disk) and then choose the appropriate way to shut down or restart the system. The save context requires storage space, not only storage space in disk, but also space in memory for swapping or buffering.

The interface, however, is to set or get how much space is allocated in the current memory to buffer the data that needs to be written to disk. Unit is byte.

3.2.6/sys/power/reserverd_size

The reserverd_size is used to indicate how much memory space is reserved for saving device-driven allocated space during->freeze () and->FREEZE_NOIRQ (). To avoid loss during the STD process.

3.2.7/sys/power/resume

This interface is also STD-specific. Normally, after rebooting, the kernel reads the image saved to disk during the late initialization process and restores the system. The interface, however, provides a way to manually read the image and restore the system in user space.

Typically, this action occurs during a system's normal operation and requires a different image to be loaded and executed.

3.2.8 Debugfs/suspend_status

This interface provides statistical information about the suspend process in the form of Debugfs, including: Number of successes, number of failures, number of freeze failures, and so on.

3.2.9/dev/snapshot

This interface is also STD-specific. It provides software STD operations to user space in the form of a character device. We will describe them in detail in the following articles.

Linux Power Management (5) _hibernate and sleep function Introduction "Go"