In , a class driver is a type of hardware device driver that can operate a large number of different devices of a broadly similar大体相似 type.
PM linux电源管理 英文文档
Most drivers will do very little；platforms with small batteries (like cellphones), will do a lot.
This writeup gives an overview of how drivers interact with system-wide power management goals，
Drivers will：
Drivers can enter low-power states as part of entering system-wide low-power states like "suspend" (also known as "suspend-to-RAM"), or "hibernation" ("suspend-to-disk").
This is something that device, bus, and class drivers驱动程序，总线，设备类驱动 collaborate on by implementing various role-specific suspend and resume methods
Some drivers can manage hardware wakeup events
Runtime Devices may also be put into low-power states while the system is running
Interfaces for Entering System Sleep States
There are programming interfaces provided for subsystems子系统 (bus type, device type,
device class) and device drivers to allow them to participate in the power management of devices they are concerned with. These interfaces cover both system sleep and
Device Power Management Operations
struct dev_pm_ops:
Subsystem-Level Methods
in struct dev_pm_ops
pointed to by the pm member of struct bus_type, struct device_type and struct class.
They are mostly of interest to the people writing infrastructure for buses,
Bus drivers总线驱动 implement these methods as appropriate for the hardware and the
drivers using it以供硬件和驱动程序
most driver code is a "device driver" that builds on top of bus-specific framework架构 code. 大多数的设备驱动程序是建立在各种特定总线架构的代码之上
these driver calls调用
wakeup
/sys/devices/.../power/wakeup files control handling of wakeup events
The "can_wakeup" flag just
records whether the device (and its driver) can physically support wakeup events.
“can_wakeup”标志表示设备（或驱动）物理上支持唤醒事件
The "should_wakeup" flag controls whether the device should try to use its wakeup mechanism. device_set_wakeup_enable() affects this flag; The initial value of should_wakeup is supposed to be false for the majority of devices.
Whether or not a device is capable of issuing wakeup events is a hardware matter, and the kernel is responsible for keeping track of it. 内核只是负责持续地跟踪这些事件的发生
whether or not a wakeup-capable device should issue wakeup events is a policy策略 decision
and it is managed by user space through a sysfs attribute: the power/wakeup file.
由用户空间通过sysfs的属性文件（power/wakeup）进行管理的
当系统迁移到睡眠状态时，驱动程序应该在让设备进入低功耗状态前通过这一函数检查，确定是否启用唤醒机制。
/sys/devices/.../power/control files
Each device in the driver model has a flag to control whether it is subject to runtime power management.设备模型 中的每个 设备都有一个标志位来控制它是否属于runtime电源管理模式
关于runtime电源管理架构的更多信息，请参看Documentation/power/runtime_pm.txt
Calling Drivers to Enter and Leave System Sleep States
wakeup-enabled devices will usually stay partly functional in order to wake the system.
可唤醒的设备一般会 保持部分功能以便适当的时候可以唤醒系统
系统退出低功耗状态时，设备驱动程序被要求恢复（resume）设备
确保调用顺序
设备驱动程序必须正确地处理这种情况
In particular, this means that a device registration may fail if the parent of
the device is suspending or has already suspended 特别是，这就意味着当父设备正在进行挂起动作（例如，已经被pm的核心选为下一个将要被挂起的设备）、或者已经挂起的情况下，注册子设备就会失败
Each phase involves executing callbacks for every device在进入下一个阶段之前，都需要为每个 设备调用属于本阶段的回调函数。不是所有的总线和设备类都会支持所有这些回调，也不是所有的驱动程序都要使用这些回调。
Most phases use bus, type, and class callbacks
(that is, methods defined in dev->bus->pm, dev->type->pm, and dev->class->pm).
当一个阶段中有多个回调要执行时，按照以下顺序调用，suspend时：<class,type,bus>，resume 时：。比如，在suspend时将会执行以下调用顺序：
dev->class->pm.suspend(dev);
dev->type->pm.suspend(dev);
dev->bus->pm.suspend(dev);
When the system goes into the standby or memory sleep state, the phases are:
prepare, suspend, suspend_noirq.
The prepare phase is meant to prevent races阻止竞态发生
prepare阶段只使用了bus的回调。回调返回后，该设备的下面将不可以注册新的子设备
emphasizing 强调
阅读(1422) | 评论(0) | 转发(0) |
