Most Linux device driver code is, most Linux Power Management (PM) code is specific to the driver. Most drivers will do very little; others, especially small battery platform (such as mobile phones), will do a lot of things.
This article outlines how the driver interacts with the system-wide power management goals, emphasizing all the elements connected to the driver model core of shared models and interfaces. The use of any particular driver as you perform specific work in the background reading domain.
Both devices Power Management Model
======================================
The driver uses these models one or both of the device into a low power state:
Sleep System Model:
Driver may enter a low power state, as the system enters the low power consumption state wide portion, such as "Suspend" (also referred to as "suspend to RAM"), or (mainly used for a system with a disk) "Hibernation" ( also known as "suspend to disk").
That is, a bus class driver, and to collaborate in the suspend and resume methods by implementing various specific role to cleanly off the hardware and software subsystems, and then reactivate them without loss of data.
Some drivers can handle a wake-up event to make the system from low-power state. You can use related: /sys/devices/.../power/wakeup file to enable or disable this feature (for Ethernet driver, ethtool using ioctl interface is also used for this purpose);
enable it might take some power, but the whole system more frequently into a low power state.
Runtime Power Management Model:
The system is running, the device can also enter a low power state, in principle, independent of other power management activities. However, the device is usually not independent (for example, unless all child devices are suspended or can not suspend parent device) with each other. Further, according to which the bus type devices, may need to
do this to perform specific operations on the device bus. Enter the low power consumption state during operation the device may require special handling during (suspend or sleep) power conversion system-wide.
For these reasons, not only the device driver itself, and the appropriate subsystem (bus type, equipment type, or device classes) PM core driver and runtime are directed to power management. As with system power management sleep case, they need to collaborate to suspend and resume through the implementation of various role-specific,
in order to cleanly shut down and re-activate the hardware in the absence of data or loss of service conditions.
Those on low-power states do not have much to say, except that they are very specific to the system and is usually specific to the device. Furthermore, if sufficient apparatus into a low power state (at run time), the effect may be very similar to the access to some system-wide low power state (sleep system) ......
and there is a synergistic effect, and therefore there are several PM uses a runtime driver may cause the system to get deeper into the power-saving option of status.
Most devices will suspend all I / O silent: there is no longer the IRQ or DMA (except for the wakeup event), no reading or writing data, and does not accept a request from an upstream driver. However, given the bus or platforms may have different requirements.
Examples of events include a wake-up alarm from the real-time clock, wake on LAN packet network, keyboard or mouse activity and media inserted or removed (for PCMCIA, MMC / SD, USB, etc.).
Enter the sleep state system interface
===========================================
Subsystems (bus type, device type, device type), and the device driver provides programming interface to allow their participation in the power management devices of interest. These interfaces covering systems and run-time power management sleep.
Device power management operations
----------------------------------
Subsystem level and a device driver level power management device and the filling operation is defined by type | struct dev_pm_ops | object to achieve. Definition include / linux / pm.h in.
The method of action contained therein will be explained below. Now, it should be remembered, finally three methods of this structure is specific to the runtime power management, the method is used during the rest of the system-wide power conversion.
There is also a deprecated "old" or "legacy" interfaces, at least for power management operations available for some subsystems. This method does not use | struct dev_pm_ops | these objects apply only in a limited way to achieve the sleep system power management.
Therefore, this document not be described, so please refer to the source code for more information about it.
Subsystem-level approach
-----------------------
The core method pause and resume devices located | struct dev_pm_ops | be | pointed ops members, or by the | | struct dev_pm_domain struct bus_type |, | struct device_type | and | struct class | pm members of pointing.
They enable people to prepare the infrastructure for the platform and buses of interest, such as PCI or USB, or device type and device class driver. They are also associated with the device driver writers which subsystem (PM field, equipment type, equipment type, and bus type) does not provide all of the power management method.
Bus drivers and hardware drivers to drive properly implement these methods; PCI works with USB different, and so on. Not many people write subsystem level drivers; most driver code is based on a specific bus framework code built "device drivers."
For more information about these driver calls, see the instructions that follow; each device will be phased according to his son to call them serial driver model tree.
The translation :: file: `/ sys / devices /.../ power / wakeup` files
To be continued. . . . .