[Power Management] RuntimePM Model of Linux Power Management

RuntimePM model of Linux power management

foreword

This article briefly introduces the concept of runtime power management (RPM), analyzes the software framework of RPM, and introduces the operating mechanism. Finally, explain the steps to modify the driver to support RPM, how to use it at the application layer, etc.

1. Concept

The Runtime PM ( runtime power management ) framework of Linux refers to runtime power management. The device turns off its own clock, reset and power when it is not running, and turns it on again when it is in use. Its purpose is to reduce power consumption when the system is running.

Here comes the problem:

How to dynamically power on or off a device?

The easiest way:
In the driver program, turn on the power in the open function and turn off the power in the close function

The above method has a disadvantage: May cause interference when multiple APPs use the device?
Solution: Add a usage count value to the driver: increase the count every time it is opened, and decrease the count once when it is closed. When the count is greater than 0, the power is turned on, and when it is equal to 0, the power is turned off. Then there is the software framework of RPM.

2. The software framework of Runtime PM

The following is a general software framework:

• The device driver (or the bus, class, etc. where the driver is located) needs to provide 3 callback functions, runtime_suspend , runtime_resume , and runtime_idle , which are used for suspend device, resume device, and idle device respectively. They are generally called by the RPM core at the right time to reduce the power consumption of the device.

• The RPM core maintains a reference count for each device, which increases the count value when getting, and decreases the count value when putting. When the count is 0, it indicates that the device is no longer in use and can be suspended immediately or after a period of time to save power consumption.

3. The operating mechanism of Runtime PM

1. Core mechanism

The core mechanism of RPM is as follows:

1) Maintain a reference count (device->power.usage_count) for each device to indicate the usage status of the device.

2) When the device needs to be used, the device driver calls the pm_runtime_get (or pm_runtime_get_sync ) interface to increase the reference count; when the device is no longer used, the device driver calls the pm_runtime_put (or pm_runtime_put_sync ) interface to reduce the reference count.

3) For each put, RPM core will judge the value of the reference count. If it is zero, it means that the device is no longer in use (idle), then use the asynchronous (ASYNC) or synchronous (SYNC) method to call the .runtime_idle callback function of the device.

4). The existence of runtime_idle is to add a buffer between idle and suspend to avoid frequent suspend/resume operations. Therefore, its duty is to judge whether the device has the conditions for suspend, and if so, suspend the device at the right time.

5) Interfaces such as pm_runtime_autosuspend and pm_request_autosuspend will start a timer , and after the timer expires, use the asynchronous (ASYNC) or synchronous (SYNC) method to call the .runtime_suspend callback function of the device, suspend the device, and record the PM status of the device at the same time . ( Prevent frequent power switching of equipment )

6) Every get, RPM core will judge the PM status of the device, if it is not active, it will use asynchronous (ASYNC) or synchronous (SYNC) method to call the .runtime_resume callback function of the device to resume the device.

Personal opinion:

2. Timing of get and put

Since get and put are the switching points of the idle state of the device, the timing of get and put is easy to grasp:

1) When actively accessing the device, such as writing registers, initiating data transmission, etc., get, increase the reference count, and tell the RPM core device to be active; after the access, put, reduce the reference count, and tell the RPM core device that it may be idle.

2) When the device has an event notification, get (maybe in interrupt processing); after the driver has processed the event, put.

3. Asynchronous and synchronous

The default interface (pm_runtime_get/pm_runtime_put, etc.) provided by RPM core adopts asynchronous calling (indicated by ASYNC flag), starts a work queue, and calls the .runtime_xxx callback function in a separate thread, which can ensure that the device driver Other modules operate normally.

In addition, if the device driver clearly knows what it wants to do, it can also use the synchronous interface (pm_runtime_get_sync/pm_runtime_put_sync, etc.), and they will directly call the .runtime_xxx callback function.

4. Runtime PM between cascaded devices

In the struct device structure, there is a parent pointer, which points to the parent device of the device (if not, it is empty). The parent device is usually a Bus, host controller, and the normal operation of the device depends on the parent device. Reflected in RPM, it is the following behavior:

1) If any device under the parent device is active, the parent must be active.

2) If any device under the parent device is idle, the parent should be notified, and the parent will use this to record the number of child devices in the active state.

3) All sub-devices under the parent device are idle, and the parent can idle.

Fourth, modify the driver and use

1. Application layer

How to use runtime PM?

The driver provides an interface, and the APP calls

• echo on > /sys/devices/…/power/control

// 导致驱动程序调用
control_store -> pm_runtime_forbid(dev); :
atomic_inc(&dev->power.usage_count);
rpm_resume(dev, 0);

• echo auto > /sys/devices/…/power/control

// 导致驱动程序调用
control_store -> pm_runtime_allow(dev); :
atomic_dec_and_test(&dev->power.usage_count)C
rpm_idle(dev, RPM_AUTO);

2. Driver layer

• Prerequisite: configure the kernel to support runtime PM

  make menuconfig
  Power management options —>
  [*] Run-time PM core functionality

2.1, general template

• Provide 3 callback functions in dev_pm_ops: runtime_suspend, runtime_resume, runtime_idle

• For runtime PM, the default state of the device is suspended. If it is running on the hardware, you need to call pm_runtime_set_active() to modify its state
  and then call pm_runtime_enable() to enable runtime PM

  Generally, the above functions are called in the probe function

• Call in the corresponding system call interface: pm_runtime_get_sync / pm_runtime_put_sync : increase/decrease the count value, and put the device in resume or suspend state

• Call pm_runtime_disable() in the remove function

2.2, autosuspend function

• If you don’t want the device to turn on and off frequently, you can use the autosuspend function.
  In the driver: execute pm_runtime_use_autosuspend to set and start the autosuspend function.
  When putting the device, execute these two functions:
  pm_runtime_mark_last_busy(&lcd_dev.dev);
  pm_runtime_put_sync_autosuspend(&lcd_dev.dev);

• In user space, execute the following command to set the time value:
  echo 2000 > /sys/devices/platform/mylcd/power/autosuspend_delay_ms

Five, examples

Refer to the kernel driver example: drivers\input\misc\bma150.c

References

Wormhole Technology-Power Management Subsystem
Wei Dongshan Embedded Phase III