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

Therefore, after the suspend_noirq (freeze_noirq, poweroff_noirq) phase, when the non-boot CPUs are shut down and the IRQs of the remaining CPUs are also shut down, the sysdev_driver.suspend phase will be started, and then Down the system goes to sleep (for hibernation the system image is created). The sequence during the resume period is: execute the sysdev_driver.resume phase, turn on the IRQ of the startup CPU, turn on other non-startup CPUs, and then start the resume_noirq phase.

The code that actually enters and exits system-level low-power states sometimes calls some hardware operations that only the boot firmware (bios? bootloader?) knows about, and then leaves the CPU running some software (from RAM or FLASH) to monitor the system and Manage wake-up sequences.

Device low power consumption (suspend) state

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

There is no standard for a device's low-power state. One device may only handle "on" and "off", but another device may support a dozen different versions of "on" (how many engines are activated?), and adding one can return it faster than a complete "off". to the "on" state.

Some buses define rules for different suspend states. PCI can give an example: after the suspend sequence is completed, a non-legacy Del PCI device cannot perform DMA or issue IRQs, and wake-up events must be signaled through the PME# bus. Several PCI standard device states are also defined, some of which are available only as options.

On the contrary, more integrated SOC processors often use IRQs as wake-up sources (so the driver calls enable_irq_wake()), and can use DMA completion interrupts as wake-up events (sometimes DMA can remain active, but the CPU and some peripherals enter sleep).

Some details here can be platform specific. In some sleep states, the system can keep some devices activated. For example, when the system is in light sleep, the LCD display will use DMA to continue refreshing. The frame buffer may even have a DSP or another non-Linux CPU to refresh, while running Linux The CPU can be in idle state.

Furthermore, depending on the state of the target system, some special things may happen. Some target system states may allow a lot of operational activity on the device, while other target system states may require a hard shutdown and then reinitialization upon resume. Furthermore, two different target systems can use the same device in different ways; like the LCD mentioned above, it can remain active in a "standby" state on one product but not on another using the same SOC. Products may work differently.

Power management notification messages

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

Some operations cannot be performed within the power management callback methods discussed above because the callback occurs too late or too early. To handle these situations, subsystems and drivers can register for power management notifications to call an operation before the process is frozen or after it is unfrozen. Generally speaking, the PM notification mechanism is suitable for performing activities that can be utilized by user space, or at least does not interfere with user space activities.

For detailed instructions, please refer to the document Documentation/power/notifiers.txt.

runtime power management

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

Many devices can be dynamically shut down while the system is running. This feature is particularly useful for devices that are not in use and allows the running system to save energy more efficiently. These devices usually support a range of runtime power states, such as "off", "sleep", "idle", "active", etc. These states are sometimes bounded by the bus used by the device, and often include system-level sleep. The status of the hardware used.

System-level power state migration can begin when some devices enter a low-power state due to rumtimepm. System sleep PM callbacks should be able to recognize this situation and reactivate them in appropriate ways, but these actions are specific to each subsystem.

Sometimes this will be determined at the subsystem level, sometimes it will be decided by the device driver itself. During system-level power state transitions, a suspended device can be kept in a state. In other cases, it may be temporarily suspended. Return the device to a full power state, for example to disable its ability to wake the system. These all depend on the specific hardware and subsystem design, and are issues that the driver should pay attention to.

When the system wakes up from sleep state, it is best to return the device to the full power state. For explanation, please refer to the document Documentation/power/runtime_pm.txt. This document has a more detailed discussion of these issues and also explains the general architecture of runtime power management.