📚 课程目录第4章内核配置深度解析（下）

内核配置深度解析（下）：CPU Idle框架、C-State与P-State管理、Device Tree中电源域配置

上一讲我们把内核配置的“上半场”走完了。今天聊点更贴近硬件的——CPU怎么“偷懒”，以及怎么告诉内核“这块电别乱用”。

说实话，低功耗调优里最容易出问题的就是CPU Idle和电源域配置。我见过太多工程师，内核编译选项全开，跑起来功耗却下不去。为什么？因为CPU根本不知道什么时候该睡，睡多深。

CPU Idle框架：让CPU学会“闭眼”

CPU Idle框架，说白了就是管理CPU空闲时该干什么。不干活的时候，总不能一直跑着空转吧？那太费电了。

这个框架的核心逻辑很简单：

检测CPU是否空闲
选择最合适的休眠深度
唤醒时恢复状态

但实际做起来，坑不少。我曾经在一个ARM平台上，发现CPU明明空闲了，功耗却只降了5%。查了半天，原来是Idle驱动没注册成功，内核一直用默认的polling方式——CPU在那空转等任务。

关键点：CPU Idle框架由 cpuidle 子系统实现，核心文件在 drivers/cpuidle/ 下。配置选项是 CONFIG_CPU_IDLE。

C-State与P-State：深度与频率的博弈

C-State和P-State，这两个概念经常被搞混。我简单解释一下：

状态类型	控制什么	典型场景
C-State	CPU休眠深度	空闲时进入C1/C2/C3
P-State	CPU运行频率/电压	负载低时降频

C-State从C0（运行）到Cx（深度休眠），数字越大，功耗越低，但唤醒延迟也越大。P-State则是在C0状态下调整频率和电压。

我个人的习惯是：先调C-State，再调P-State。因为C-State决定了基础功耗，P-State是在这个基础上的精细调节。

小技巧：查看当前C-State使用情况，可以用 cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name。如果发现某个深度状态从未被使用，说明你的Idle governor没选对。

C-State配置实战

内核里C-State的配置主要涉及两个governor：

menu governor：根据预测的idle时间选择状态，适合大多数场景
ladder governor：逐级加深休眠，适合延迟敏感场景

我建议默认用menu。但要注意，menu governor依赖 CONFIG_NO_HZ_IDLE 或 CONFIG_NO_HZ_FULL，否则预测不准。

# 内核配置示例
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_CPU_IDLE_GOV_LADDER=y
# 如果你的CPU支持，可以开启
CONFIG_ARM_CPUIDLE=y

嗯，这里要注意：不是所有CPU都支持所有C-State。比如有些ARM Cortex-A系列只支持WFI（Wait For Interrupt），相当于C1。强行配置更深的状态，系统可能会挂掉。

避坑指南：我曾经在某个项目里，为了省电把C-State最大深度设成了C3。结果WiFi模块一工作，CPU唤醒延迟太大，导致数据丢包。后来只能回退到C2。记住：省电和省心，有时候得权衡。

P-State管理：动态调频的学问

P-State管理由 cpufreq 子系统负责。它决定了CPU在运行时用多高的频率。

常见的governor有：

performance：最高频率，性能优先
powersave：最低频率，省电优先
ondemand：根据负载动态调整
conservative：缓慢调整，适合平滑场景
schedutil：基于调度器提示，效率最高

我个人推荐 schedutil。它直接利用调度器的负载信息，响应快，功耗控制也精准。但需要内核开启 CONFIG_CPU_FREQ_GOV_SCHEDUTIL。

# 查看当前governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 切换governor
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

关键点：P-State的生效前提是硬件支持DVFS（动态电压频率调整）。如果硬件不支持，配置了也没用。

Device Tree中电源域配置

Device Tree（设备树）是嵌入式Linux里描述硬件信息的关键。电源域（Power Domain）的配置，直接影响哪些设备可以独立断电。

电源域的概念很简单：把一组设备放在同一个电源域里，当所有设备都空闲时，可以一起断电。这比单独控制每个设备要高效得多。

在Device Tree里，电源域通常用 power-domains 属性来描述：

/dts-v1/;

/ {
    soc {
        #power-domain-cells = <1>;
        
        pd_core: power-domain@0 {
            compatible = "generic-power-domain";
            #power-domain-cells = <0>;
            domain-id = <0>;
        };
        
        pd_periph: power-domain@1 {
            compatible = "generic-power-domain";
            #power-domain-cells = <0>;
            domain-id = <1>;
        };
        
        uart0: serial@ff000000 {
            compatible = "my-uart";
            reg = <0xff000000 0x1000>;
            power-domains = <&pd_periph>;
        };
    };
};

这段代码定义了两个电源域：pd_core 和 pd_periph。UART0被分配到了 pd_periph 域。当UART0和其他同域设备都空闲时，内核可以关闭整个 pd_periph 域的电源。

小技巧：查看当前电源域状态，可以用 cat /sys/kernel/debug/pm_genpd/pm_genpd_summary。如果某个域一直处于“on”状态，说明有设备没正确注册到电源域框架里。

电源域配置的常见坑

我遇到过最典型的问题：某个外设驱动没有调用 pm_runtime_put_sync，导致电源域一直无法关闭。功耗直接多了几十毫瓦。

另一个坑是：电源域之间的依赖关系没配好。比如A域依赖B域供电，B域断电时A域也得跟着断。这个依赖关系需要在Device Tree里用 power-domains 属性嵌套描述。

pd_a: power-domain@2 {
    compatible = "generic-power-domain";
    #power-domain-cells = <0>;
    power-domains = <&pd_core>;  // A域依赖Core域
};

避坑指南：我曾经在配置电源域依赖时，写成了循环依赖——A依赖B，B依赖A。结果内核启动时直接死锁。嗯，这种低级错误，犯过一次就再也不会忘了。

知识结构总览

为了让你更直观地理解这三部分的关系，我画了一张图：

从这张图可以看得很清楚：CPU Idle框架是总调度，C-State和P-State是具体手段，电源域则是硬件层面的支撑。三者缺一不可。