蜗窝科技

Linux PM QoS framework(3)_per-device PM QoS

作者：wowo 发布于：2015-2-26 22:44 分类：电源管理子系统

per-device PM QoS是针对指定设备的QoS framework，背后的思考如下：

1）resume_latency

在Runtime PM的框架下，当device的引用计数减为0的时候，RPM会suspend该device。不过，device进入suspend状态以及从suspend状态resume是需要消耗时间的（相关信息保存在pm domain中），而系统其它实体（如用户空间程序）可能对该设备的响应时间有要求，这就是一种形式的QoS request，称作resume_latency。

per-device PM QoS framework会提供相应的接口，收集指定设备的resume_latency request，并提供给Runtime PM，它在suspend设备时，会考虑这种需求，并决定是否suspend设备。

2）latency_tolerance

一些复杂的设备，在运行状态（active）时，为了节省功耗，也有可能自行进入某些省电状态，相应的，设备的响应速度可能降低。如果该设备足够智能，可能会提供一个回调函数（.set_latency_tolerance，位于dev_pm_info结构中），以便设置最大的延迟容忍时间。这称作latency_tolerance。

对per-device PM QoS来说，需要提供一种机制，收集所有的、针对某个设备的latency_tolerance需求，并汇整出可以满足所有需求的latency_tolerance，通过设备的回调函数告知设备。

3）no power off/remote wakeup

在Runtime PM的框架下，设备suspend之后，还可以进一步通过pm domain关闭该设备的供电，以节省功耗。但关闭供电时，除了要考虑对设备resume_latency的需求之外，还要考虑该设备是否允许关闭供电，以及该设备是否需要作为一个唤醒源（remote wakeup）。

这是另一种形式的QoS request，称作per-device PM QoS flag，表示系统其它实体对该设备的一些特定行为的需求。当前的flag有两种：

PM_QOS_FLAG_NO_POWER_OFF，表示不允许设备断电
PM_QOS_FLAG_REMOTE_WAKEUP，表示设备应具备唤醒功能

这两个flag可以通过或操作，同时生效。

因此，per-device PM QoS framework的功能，就是抽象上面两类需求，包括：向requestor提供QoS request的add、update、remove等API，包括内核空间API和用户空间API；汇整、整理这些request；向电源管理有关的service（主要是pm domain framework）提供汇整后的request信息，以便这些service可以做出正确的决定。

下面将会结合source code(位于drivers/base/power/qos.c中），介绍上面的实现逻辑。

阅读全文>>

标签: Linux Kernel pm_qos per-device

评论(9) 浏览(15507)