1 Introduction
The Runtime PM (runtime power management) framework of Linux refers to runtime power management. When the device is not running, it will reset its own clock, reset and power off (the management framework of the clock and the management framework of the regulator have been introduced in previous articles. The reset The management framework will be introduced in an article later), and then open it when using it. Its purpose is to reduce power consumption when the system is running.
Compared with system sleep wake-up power management, RPM adopts a divide-and-conquer management idea, giving specific power consumption control strategies and control rights to each driver. When the device does not need to work, it can perform corresponding low-power control , This can not only ensure that the system can work normally, but also reduce the power consumption when the system is running as much as possible. The devices here may be peripherals, such as sensors, lcdc, etc. The devices here may also be some IPs inside the SOC, such as codec, dsp, usb, etc.
When designing the SOC, in order to reduce the power consumption of the operation as much as possible, some power domains will be divided according to the functions of the business scenarios. Generally, the power domains will contain several functional IPs, so that in different scenarios, they can be closed as much as possible and not used as needed. power domain. In fact, these power domains also have corresponding software management frameworks. The rpm framework and the pd framework have a strong coupling relationship, so this article will also give a rough introduction to the pd framework, and an article will be dedicated to the pd framework later.
2. Framework
linux rpm framework
2.1 divers
Device drivers (including bus, class, and power domain) implement three callbacks related to runtime pm: runtime_idle/runtime_suspend/runtime_resume. runtime_suspend is used to implement low-power operation of the device, and runtime_resume is used to implement low-power recovery-related operations of the device. , runtime_idle is a transition of runtime_suspend, used to buffer frequent suspend and resume. It will determine whether the device has the conditions for suspending. If so, it will suspend the device at the right time.
The runtime_suspend and runtime_resume callback functions will call the clock switch, reset, and power switch interfaces provided by the clock framework/reset framework/regulator framework.
2.2 Runtime PM core
Runtime pm core mainly provides three types of function interfaces:
Runtime pm core will provide the enable/disable interface to the device driver, which is used by the device driver to decide whether to turn on or off RPM. It also provides get and put interfaces to the device driver, which is used to decide when to enter or restore the low power consumption of the device. After the driver calls the get and put interfaces, RPM will call the runtime_suspend/runtime_resume interface implemented by each device driver.
Regarding the timing of calling the get/put interface that determines whether the device enters low-power consumption, the get interface is generally called before operating the device-related registers, and the put interface is called after the related registers are operated. Or call it in the open, release, start, stop and other interfaces of the device driver. User-level services call these interfaces of the driver through ioctrl or the file node provided by the driver.
- RPM switch interface in driver
When the driver initializes the device, call pm_rumtime_enable() to enable the runtime pm function of the device. When the device is uninstalled, call pm_rumtime_disable() in the remove function to turn off the runtime pm function of the device. For the implementation of these two interfaces: use a variable (dev->power.disable_depth) to record the depth of disable. As long as disable_depth is greater than zero, it means that the RPM function is turned off. At this time, RPM-related API calls (such as suspend/resume/put/get, etc.) will return failure EACCES.
When RPM is initialized, the disable_depth of all devices will be set to 1, which is the disabled state. When the driver is initialized, pm_rumtime_enable is called at the end of the probe function to enable RPM as needed, and pm_rumtime_disable is called in the driver's remove function to turn off RPM.
- RPM get operation class interface
When the driver thinks that its device needs to work (exit low power consumption), it calls pm_rumtime_get()/pm_rumtime_get_sync() to request the RPM core to return the device to normal. If the conditions are met, the RPM core will execute the driver's runtime_resume callback function to configure the device. for working status.
For the implementation of the get operation interface: each device maintains a usage_count variable to record the usage of the device. When it is greater than 0, it means that the device is in use. When the value changes from 0 to non-0, the runtime_resume callback implemented by the device driver will be called to let the device exit the low-power state. When equal to 0, it means that the device is no longer used. When the value changes from non-0 to 0, the runtime_suspend callback implemented by the device driver will be called to put the device into a low-power state.
There are generally two types of this type of interface. The difference between the two types of APIs can be intuitively seen through the names: pm_rumtime_get() is used for asynchronous operations, while pm_rumtime_get_sync () is used for synchronous operations. If you expect to access the device immediately after performing the get operation, then use the pm_rumtime_get_sync () interface, because the pm_rumtime_get () interface will put some core operations into a work queue (workqueue) for delayed execution.
- RPM put operation
When the driver believes that its device does not need to work (shut down), it calls pm_rumtime_put()/pm_rumtime_put_sync() to request the RPM core that the device enters low power consumption. If the conditions are met, the RPM core will execute the driver's runtime_suspend callback function and configure The device enters a low power state.
2.3 power domain framework
A power domain may contain multiple IPs, and each IP may correspond to one or more devices. These devices will describe the binding relationship with the power domain in dts. When the system is initialized, the power domain will be placed in a linked list, and then the device will be hung in the linked list under the power domain node according to the relationship between the dts and the power domain described in the device.
When a device driver calls through the put interface to reduce the usage_count from 1 to 0, the runtime_suspend interface registered in the power domain will be called first. In this interface, the runtime_suspend of the device driver will be called first, and then traverse the power domain. Whether all devices allow suspend (whether the usage_count of each device driver is 0), if it is allowed, it will directly call the interface to close the power domian, otherwise it will return directly. When a device driver calls through the get interface to increase the usage_count from 0 to 1, the runtime_resume interface registered by the power domain will be called first. In this interface, the power domain will be powered on first, and then the corresponding device driver will be called. The runtime_resume callback function allows the device to exit low power consumption.
2.4 runtime pm sysfs
For devices that support rpm, there are multiple rpm-related file nodes under the corresponding device node, which are control, runtime_susupend_time, runtime_active_time, autosuspend_delay_ms, runtime_status.
/sys/devices/.../power/control
- on - Call the pm_runtime_forbid interface, increase the reference count of the device, and then resume the device.
- auto - Call the pm_runtime_allow interface to reduce the device's reference count. If the device's reference count is 0, idle the device.
/sys/devices/.../power/runtime_status
- active - The status of the device is normal operating status.
- suspend- The state of the device is low power mode.
- suspending-The status of the device is changing from active->suspend.
- resuming-The status of the device is changing from suspend->active.
- error-An error occurs in the device runtime, and the runtime_error flag is set at this time.
- unsupported - The device's runtime is not enabled, and the disable_depth flag is set.
/sys/devices/.../power/runtime_suspend_time
- The time the device is in the suspended state
/sys/devices/.../power/runtime_active_time
- The time the device is in active state
/sys/devices/.../power/autosuspend_delay_ms
- How long does it take for the device to be suspended in idle state, and set the delay time for delaying suspend.
3. Data structure
linux rpm data structure
4. Process
4.1 rpm related operation process during initialization process
Device rpm initialization process
4.2 rpm related operation procedures during the remove process
rpm related operation process during device removal
4.3 rpm related operation process during shutdown process
rpm related operation process during shutdown process
4.4 rpm related operation process during sleep and wake-up process
rpm related operation process during sleep and wake-up process
4.5 Workflow
There are four main states in Runtime PM:
- Active
- Suspending
- Suspended
- Resuming
There may also be several basic Power manager operations such as reset, power on, and power off, and device management operations, as well as enabling some cores in the device and shutting down some cores during actual operation. These all belong to Power manager management. part.
The specific status switching is as follows:
rpm status switching diagram
pm_runtime_get
pm_runtime_put
(I usually share useful articles on Linux technology. Follow me and you can receive push notifications of related articles on a regular basis. I have the same name on Zhihu and WeChat: Hackers and Photographers)