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

内核配置深度解析（上）：CPU Frequency Scaling（CPUFreq）框架、Governor选择与驱动配置

说到嵌入式Linux的低功耗优化，CPUFreq绝对是绕不开的第一道坎。说白了，它就是动态调整CPU频率和电压的机制——CPU不忙的时候降频省电，忙的时候提频保证性能。这个框架在内核里已经非常成熟，但很多人配置的时候就是选个governor完事，结果要么性能不够，要么功耗没降下来。

我个人习惯把CPUFreq分成三层来看：核心框架层、Governor策略层和底层驱动层。这三层配合好了，才能真正做到“该快的时候快，该省的时候省”。

核心观点：CPUFreq不是简单的“省电模式”开关，而是一个动态调频调压的闭环系统。配置的关键在于理解你的负载特征，然后选择合适的governor和驱动。

1. CPUFreq框架：内核里的“调度中心”

CPUFreq框架在内核中的位置是 drivers/cpufreq/。它提供了一套统一的接口，让上层的governor和下层的硬件驱动能够协同工作。框架本身不关心你怎么调频，它只负责把governor的决策传递给驱动，再把驱动的状态反馈给governor。

我记得第一次看这个框架的代码时，最让我印象深刻的是它的通知链（notifier chain）机制。频率变化时，框架会通知所有注册了监听的内核模块——比如温度传感器要调整阈值、总线频率要同步调整等等。这个设计很巧妙，但也是个坑：如果你注册了太多通知回调，调频延迟会明显增加。

实战建议：在配置内核时，检查 CONFIG_CPU_FREQ 是否开启。对于大多数嵌入式平台，还需要开启 CONFIG_CPU_FREQ_STAT 来获取调频统计信息，这对后续调优很有帮助。

2. Governor选择：四种策略，四种性格

Governor是CPUFreq的大脑。它决定“什么时候该调频、调到多少”。内核里常用的有四种，我按自己的理解排了个序：

Governor	策略特点	适用场景	功耗表现
performance	始终运行在最高频率	性能敏感、不考虑功耗	最差
powersave	始终运行在最低频率	后台任务、待机场景	最好
ondemand	负载超过阈值时跳频到最高	传统嵌入式设备	中等
schedutil	基于调度器负载采样，平滑调频	现代多核、交互式场景	优秀

这里我想重点聊聊 schedutil。它是在内核 4.7 之后引入的，跟之前的governor最大的区别是：它直接从调度器获取CPU利用率，而不是靠定时器去采样。这意味着什么？调频的响应速度更快，而且更精准。

我曾经在一个视频编解码的项目里做过对比：同样的负载，用ondemand时，CPU频率在1.2GHz和1.8GHz之间来回跳，功耗曲线像锯齿一样；换成schedutil后，频率变化平滑了很多，整体功耗降低了约12%。

注意：schedutil依赖调度器的 CONFIG_SCHED_MC 或 CONFIG_SCHED_SMT 支持。如果你的内核没有开启这些选项，schedutil可能无法正常工作，会回退到类似ondemand的行为。

3. 驱动配置：让框架和硬件“对上话”

Governor做决策，驱动来执行。不同的硬件平台有不同的调频方式，内核里对应的驱动也不一样。常见的有：

acpi-cpufreq：x86平台的标准驱动，通过ACPI接口调频
cpufreq-dt：设备树驱动的通用方案，ARM平台常用
imx-cpufreq-dt：NXP i.MX系列专用驱动
qcom-cpufreq-hw：高通平台的硬件调频驱动

配置驱动时，我建议你重点关注两个参数：过渡延迟（transition latency）和可用频率表（frequency table）。过渡延迟决定了governor的采样周期——延迟越大，调频越迟钝。频率表则决定了你能在哪些频率点之间切换。

举个例子，在设备树中配置cpufreq-dt时，通常会这样写：

cpu0: cpu@0 {
    compatible = "arm,cortex-a7";
    operating-points = <
        1200000  1250000
        1000000  1150000
        800000   1050000
        500000   950000
    >;
    clocks = <&clk IMX6QDL_CLK_ARM>;
    clock-latency = <61036>;  // 单位：ns
};

这里 operating-points 定义了频率和电压的对应关系，clock-latency 就是过渡延迟。我见过有人把延迟设成0，结果内核直接报错——因为governor无法容忍“零延迟”的假设。

避坑指南：我曾经在一个项目里发现，cpufreq-dt驱动在启动时没有正确解析设备树中的频率表，导致系统只能运行在最低频率。排查了半天，最后发现是设备树中频率值的单位写错了——应该是kHz，但写成了Hz。这种低级错误，真的让人抓狂。

4. 知识体系总览

下面这张图是我自己整理的CPUFreq知识结构，你可以把它当作配置时的“地图”：

5. 配置实战：从零开始配一个CPUFreq

假设你手上有一块基于ARM Cortex-A7的板子，运行Linux 5.10内核。下面是我建议的配置步骤：

开启内核选项：确保 CONFIG_CPU_FREQ=y，然后按需选择governor和驱动。
检查设备树：确认CPU节点下有 operating-points 和 clock-latency。
启动后验证：通过 /sys/devices/system/cpu/cpu0/cpufreq/ 下的文件查看当前频率和可用governor。
切换governor：echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
监控调频行为：使用 cpupower monitor 或 cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

重要提醒：有些SoC的调频需要同时调整CPU电压，这涉及到PMIC（电源管理芯片）的驱动。如果电压没跟上，频率调上去后系统会直接死机。我踩过这个坑——当时调频到1.4GHz，电压还是1.0V，结果板子直接黑屏。所以，一定要确认你的驱动支持同步调压。

嗯，CPUFreq这部分内容其实挺多的，但核心就是这三层：框架、governor、驱动。配置的时候别贪多，先搞清楚你的负载特征，再选governor，最后调驱动参数。这样一步步来，功耗和性能的平衡点自然就找到了。