Power management of linux driver - linux power management architecture (3)

Copyright (c) 2010 Rafael J. Wysocki, Novell Inc.

Copyright (c) 2010 Alan Stern stern@rowland.harvard.edu

*************************************************** ***********

This article was translated by DroidPhone on 2011.8.5

*************************************************** ***********

Most of the Linux source code belongs to the device driver code. Therefore, most of the power management (PM) code also exists in the driver. Many drivers may only do a small amount of work, while others, such as those using battery-powered hardware platforms (mobile phones, etc.), will do a lot of work in power management.

This document provides a general description of how the driver interacts with the power management part of the system, especially the sharing of models and interfaces related to the driver core. It is recommended that people who are engaged in driver-related fields can learn about it through this document. background knowledge.

Two models of device power management

===================================

Drivers can use one of these models to put the device into a low-power state:

1. System sleep model:

The driver, as part of the program, follows system-level low-power states like "suspend" (also called "suspend-to-RAM"), or for systems with hard drives, can enter "hibernation" (also called "suspend-to-RAM"). -disk").

In this case, the driver, bus, and device class driver work together to clearly shut down the hardware device and various software subsystems through various device-specific suspend and resume methods, and then reactivate the hardware without losing data. equipment.

Some drivers can manage hardware wake-up events that can cause the system to leave a low-power state. This feature can be turned on and off through the corresponding /sys/devices/.../power/wakeup file (for Ethernet drivers, ethtool achieves the same purpose through the ioctl interface); enabling this feature may cause additional functionality consumption, but it gives the entire system more opportunities to enter a low-power state.

2. Runtime power management model:

This model allows the device to enter a low-power state during system operation, in principle, independently of other power management activities. However, devices generally cannot be controlled individually (for example, a parent device cannot enter suspend unless all of its child devices have entered the suspend state). In addition, depending on the bus type, some special operations may have to be done to achieve the purpose. If the device enters a low-power state during system operation, special handling must be made during system-level power state transitions (suspend or hibernation).

For this reason, not only the device driver itself, but also the corresponding subsystem (bus type, device type, device class) driver and power management core will be involved in the work of rumtime power management. For example, when the system is sleeping, the above modules must cooperate with each other to implement various suspend and resume methods so that the hardware can enter a low-power state and continue to provide services after waking up without losing data.

There isn't much we can say about the definition of low-power states, as they are often system-specific or even specific to a device. If enough devices enter a low-power state while the system is running, the effect is actually very similar to entering a system-level low-power state. In this way, some drivers can use rumtime power management to put the system into a state similar to deep power saving.

Most devices that enter the suspend state will stop all I/O operations: there will be no DMA or IRQ requests (except those that need to wake up the system), no data reading or writing, and no requests from upper-layer drivers will be accepted. This will have different requirements for different buses and platforms.

Some examples of hardware wake-up events: alarm initiated by RTC, arrival of network packets, keyboard or mouse activity, insertion or removal of media (PCMCIA, MMC/SD, USB, etc.).

Interface to enter system sleep state

================================================== =

The kernel provides corresponding programming interfaces for various subsystems (bus type, device type, device class) and drivers so that they can participate in the power management of the devices they care about. These interfaces cover system-level sleep and runtime-level management.

Device power management operations

================================================== =

Device power management operations for subsystems and drivers are defined in the dev_pm_ops structure:

struct dev_pm_ops {

         int(*prepare)(struct device *dev);

         void(*complete)(struct device *dev);

         int(*suspend)(struct device *dev);

         int(*resume)(struct device *dev);

         int(*freeze)(struct device *dev);

         int(*thaw)(struct device *dev);

         int(*poweroff)(struct device *dev);

         int(*restore)(struct device *dev);

         int(*suspend_noirq)(struct device *dev);

         int(*resume_noirq)(struct device *dev);

         int(*freeze_noirq)(struct device *dev);

         int(*thaw_noirq)(struct device *dev);

         int(*poweroff_noirq)(struct device *dev);

         int(*restore_noirq)(struct device *dev);

         int(*runtime_suspend)(struct device *dev);

         int(*runtime_resume)(struct device *dev);

         int(*runtime_idle)(struct device *dev);

};

This structure is defined in include/linux/pm.h, and their functions will be described next. For now, we just have to remember that the last three methods are specifically for rumtime pm, the others are for system-level power state migration.

In some subsystems, there are still so-called "outdated" or "traditional" power management operation interfaces. This method does not use the dev_pm_ops structure and is only applicable to system-level power management methods. This article will not It will be explained, if you want to understand please look directly at the source code of the kernel.

Subsystem-Level method

--------------------------------------------------------

The key methods for the device to enter suspend and resume are in the pm members of the bus_type structure, device_type structure and class structure. It is a pointer to the dev_pm_ops structure. In most cases, these are the concerns of the maintainers of a specific bus architecture (such as PCI or USB or a device class and device class).

Bus drivers implement these methods appropriately for the hardware and drivers to use them; because PCI and USB work in different ways. Only a few people write subsystem-level drivers; most device drivers are built on top of various bus-architecture-specific code.

These calls will be described in more detail later; they will be called device by device along the parent-child device model tree.

/sys/devices/.../power/wakeup files

--------------------------------------------------

All devices in the device model have two flags to control wake events (which can cause the device or system to exit a low-power state). Assume that the two flag bits are initialized by the bus or device driver using device_set_wakeup_capable() and device_set_wakeup_enable(), which are defined in include/linux/pm_wakeup.h.

The "can_wakeup" flag indicates that the device (or driver) physically supports wake events, and the device_set_wakeup_capable() function affects this flag. The "should_wakeup" flag controls whether the device should attempt to enable its wakeup mechanism. device_set_wakeup_enable() affects this flag. Most drivers do not actively modify their values. The initial value of should_wakeup for most devices is set to false. There are exceptions, such as the power button, keyboard, and network cards with wake-on-LAN function set by ethtool.

Whether the device has the ability to issue wake-up events is a hardware issue, and the kernel is only responsible for continuously tracking the occurrence of these events. On the other hand, whether a wake-capable device should initiate a wake-up event is a policy issue, which is managed by user space through the sysfs property file (power/wakeup). User space can write "enabled" or "disabled" to set or clear the shoe_wakeup flag. Correspondingly, when reading the file, if the can_wakeup flag is true, the corresponding string is returned. If can_wakeup is false, an empty value is returned. A string indicating that the device does not support wake events. (It should be noted that although an empty string is returned, writing to the file will still affect the should_wakeup flag)

The device_may_wakeup() function will return true only if both flags are true. When the system transitions to sleep, the driver should check through this function to determine whether the wake-up mechanism is enabled before putting the device into a low-power state. However, in rumtime power management mode, wake-up events will be enabled regardless of whether the device and driver support it or whether the should_wakeup flag is set.

/sys/devices/.../power/control files

--------------------------------------------------------

Each device in the device model has a flag bit to control whether it belongs to runtime power management mode. This flag called runtime_auto is initialized by the bus type (or other subsystem) using pm_rumtime_allow() or pm_rumtime_forbid(). The default value is to allow rumtimepm.

User space can modify this flag by writing "on" or "auto" to the device's sysfs file power/control. Writing "auto" is equivalent to calling pm_rumtime_allow(), allowing the device to be rumtimepmed by the driver. Writing "on" is equivalent to calling pm_rumtime_forbid(), the flag bit is cleared, the device will return to the full power state from the low power state, and prevents the device from performing runtime power management. User space can also read this file to check the current value of runtime_auto.

The device's runtime_auto flag does not affect system-level power state migration. Of particular note is that even though the runtime_auto flag is cleared, the device is also brought into a low-power state when the system-level power state transitions to sleep.