Linux的电管理架构.docxVIP

Linux的电源管理架构 Linux的源代码里，大部分都属于设备驱动程序的代码，因此，大多数电源管理（PM）的代码也是存在于驱动程序当中。很多驱动程序可能只做了少量的工作，另外一些，例如使用电池供电的硬件平台（移动电话等）则会在电源管理上做了大量的工作。 这份文档对驱动程序如何与系统的电源管理部分交互做了一个大概的描述，尤其是关联到驱动程序核心中的模型和接口的共享，建议从事驱动程序相关领域的人通过本文档可以了解相关的背景知识。 设备电源管理的两种模型 =================================== 驱动程序可以使用其中一种模型来使设备进入低功耗状态： 1. 系统睡眠模型： 驱动程序作为一部分，跟随系统级别的低功耗状态，就像”suspend”（也叫做”suspend-to-RAM”），或者对于有硬盘的系统，可以进入”hibernation”（也叫做”suspend-to-disk”）。 这种情况下，驱动程序，总线，设备类驱动一起，通过各种特定于设备的suspend和resume方法，清晰地关闭硬件设备和各个软件子系统，然后在数据不被丢失的情况下重新激活硬件设备。 有些驱动程序可以管理硬件的唤醒事件，这些事件可以让系统离开低功耗状态。这一特性可以通过相应的/sys/devices/…/power /wakeup文件来开启和关闭（对于Ethernet驱动程序，ethtool通过ioctl接口达到同样的目的）；使能该功能可能会导致额外的功耗， 但他让整个系统有更多的机会进入低功耗状态。 2. Runtime 电源管理模型： 这种模型允许设备在系统运行阶段进入低功耗状态，原则上，他可以独立于其他的电源管理活动。不过，通常设备之间不能单独进行控制（例如，父设备不能 进入suspend，除非他的所有子设备已经进入suspend状态）。此外，依据不同的总线类型，可能必须做出一些特别的操作来达到目的。如果设备在系 统运行阶段进入了低功耗状态，在系统级别的电源状态迁移时（suspend或hibernation）就必须做出特别的处理。 正因为这个原因，不仅仅设备驱动程序本身，相应的子系统（bus type,device type,device class）驱动程序和电源管理核心也会被卷入到rumtime电源管理的工作中来。比如当系统睡眠时，以上的各模块必须互相合作来实现各种多样的 suspend和resume方法，以便让硬件进入低功耗状态，唤醒后继续提供服务而不丢失数据。 对于低功耗状态的定义，我们没有太多可以说的，因为他们通常特定于系统，甚至特定于某个设备。如果在系统运行状态，足够多的设备进入了低功耗状态， 这时的效果其实和进入了系统级别的低功耗状态非常相像。这样一些驱动程序可以利用rumtime电源管理让系统进入一种类似深度省电的状态。 大多数进入suspend状态的设备会停止所有的I/O操作：不会有DMA或者IRQ请求（需要唤醒系统的除外），不会有数据的读写，不再接受上层驱动的请求。这对于不同的总线和平台会有不同的要求。 关于硬件唤醒事件的一些例子：由RTC发起的闹钟，网络数据包的到达，键盘或者鼠标的活动，媒体的插入或移除(PCMCIA,MMC/SD,USB,等等)。 进入系统睡眠状态的接口 =================================================== 内核为各个子系统（bus type,device type, device class）和驱动程序提供了相应的编程接口，以便它们参与它们所关心的设备的电源管理。这些接口覆盖了系统级别的睡眠和runtime级别的管理。 设备电源管理操作 =================================================== 子系统和驱动程序的设备电源管理操作，都定义在dev_pm_ops结构中： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 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(*powerof