1. regulator framework 到底在解决什么问题1.1 从一个真实的调试现场说起几年前我在做一个车载中控项目主控是某国产 SoC外挂了一颗 PMIC 给 CPU、DDR、eMMC、WiFi 模组分别供电。板子回来之后发现一个诡异现象系统启动到一半WiFi 模组偶尔枚举失败概率大概十次里有一次。一开始怀疑是模组本身的问题换了两批模组还是复现又怀疑是 SDIO 时序调了半天也没用。最后拿示波器去量 WiFi 那路供电才发现上电时序不对——WiFi 的 1.8V 比 3.3V 先起来了几十毫秒模组内部 IO 在 3.3V 还没建立时就被拉高了导致偶发性的上电复位异常。这个问题最终的解法就是在设备树里给这两路电加上regulator-boot-on和regulator-always-on的约束并且用vin-supply把两路电的父子关系串起来让内核在初始化阶段按正确的顺序使能。改完之后那个偶发失败再也没出现过。这件事让我意识到regulator framework 不是一个锦上添花的子系统而是嵌入式 Linux 里真正决定硬件能不能稳定跑起来的基础设施。很多人学内核功耗子系统一上来就去看cpufreq、cpuidle、runtime pm觉得那些才是功耗的正主结果忽略了 regulator 这一层——而恰恰是这一层管着所有用电设备的水龙头。1.2 regulator 是什么为什么需要一套框架用生活化的类比regulator 就是电路板上的稳压电源模块它把输入电压比如电池的 3.7V 或者适配器的 5V转换成某个器件需要的电压比如 1.2V、1.8V、3.3V并且能控制这一路电的开和关。一颗 PMIC 上通常集成好几路甚至十几路 regulator每一路对应一个供电域。问题在于如果每个驱动都自己去操作 PMIC 的寄存器来开关电、调电压会带来几个麻烦重复造轮子每颗 PMIC 的寄存器布局都不一样驱动里到处散落着硬件相关的代码。无法协调两个设备共用一路电A 设备想关B 设备还在用谁说了算时序失控上电顺序、父子供电关系某路电的输入来自另一路电没人统一管理。功耗统计缺失系统想知道现在哪些电是开着的没有统一入口。regulator framework 就是内核给出的统一答案。它把供电能力抽象成一个struct regulator对象把供电控制器抽象成struct regulator_dev把供电控制器驱动抽象成struct regulator_descstruct regulator_ops。上层设备驱动只需要通过regulator_get()拿到一个句柄然后regulator_enable()、regulator_disable()、regulator_set_voltage()完全不用关心底下是 I2C 的 PMIC 还是 GPIO 控制的 LDO。1.3 这套框架适合谁来深入我把读者大致分三类你可以对号入座BSP 工程师天天和设备树、PMIC 打交道需要把板子上的每一路电都配正确。这类人最需要吃透regulator的 consumer 接口和设备树绑定。驱动开发者写外设驱动时经常要regulator_get但可能只知道照着别人的代码抄不清楚引用计数、enable 时序背后的逻辑。这类人需要理解 provider 和 consumer 的交互模型。内核爱好者/面试准备者功耗子系统是内核面试的高频考点regulator 又是其中结构最清晰、最适合拿来练手的一个框架。这类人需要从整体架构到关键数据结构都过一遍。接下来的内容我会按整体设计思路 → 核心数据结构 → 设备树与 provider 注册 → consumer 使用 → 常见问题排查这条线展开尽量把每个为什么这么设计讲透而不是只罗列 API。2. 整体架构与设计思路拆解2.1 分层模型provider、consumer 与 coreregulator framework 的代码集中在drivers/regulator/目录下核心文件是core.c它承担了框架的大脑角色。整个框架可以清晰地分成三层层次角色典型代码位置职责上层consumer消费者各外设驱动申请、使能、调压、释放中层regulator coredrivers/regulator/core.c引用计数、约束校验、级联管理、sysfs下层provider提供者drivers/regulator/*-regulator.c操作具体硬件寄存器这种分层的好处是关注点分离consumer 只关心我要 1.8V、我要开电provider 只关心怎么把寄存器写对而 core 负责把两者撮合起来并在中间做各种约束检查。我特别喜欢用自来水公司来类比这个模型provider 是自来水厂和管网core 是水务调度中心consumer 是每家每户。你打开水龙头enable的时候不需要知道水是从哪个水厂来的调度中心会保证有水、水压对、并且在你不用的时候不会把整条主管道关掉因为别人还在用。2.2 为什么要有引用计数这是 regulator framework 里最容易被忽视、但最容易出 bug 的机制。考虑这样一个场景eMMC 和 SD 卡槽共用一路 3.3V。eMMC 驱动在 probe 时regulator_enable了一次SD 驱动在插卡时也regulator_enable了一次。如果框架不做计数SD 卡拔出来时驱动调用regulator_disable这一路电就被关了eMMC 直接掉电系统崩溃。所以 core 里维护了一个enable_count。每次regulator_enable加一regulator_disable减一只有减到 0 时才真正去操作硬件关电。这个设计看起来简单但实际项目里踩坑的人非常多后面第 4 章我会专门讲几个典型翻车案例。注意引用计数是每个 consumer 句柄维度的不是全局的。同一个驱动里regulator_get两次会拿到两个句柄各自计数这一点在写代码时要特别小心。2.3 约束constraints把硬件限制写进软件regulator 有一个很重要的概念叫constraints约束。为什么需要它因为硬件是有物理限制的某路 LDO 只能输出 1.8V 到 3.3V你不能让它输出 5V某路电是 always-on 的软件不允许关某路电的电压必须由另一路电的电压决定比如 DDR 的 VDDQ 跟随 VDD。这些限制如果只写在驱动里换个板子就得改代码。所以内核把它们抽象成struct regulation_constraints通过设备树或者板级文件传入。core 在每次 consumer 请求调压或开关时都会拿请求值和 constraints 比对不合法就直接返回错误。常见的约束字段有这么几个我列个表方便对照约束字段含义典型用途min_uV/max_uV允许的电压范围防止调压越界always_on永远不关给 CPU、DDR 供电boot_on启动时默认开需要早期上电的器件valid_ops_mask允许的操作集合限制某路电只能开关不能调压valid_modes_mask允许的工作模式区分普通模式和低功耗模式2.4 级联供电supply 链现实中的供电往往不是平铺的而是有层级的。比如电池 → 主 PMIC 的 buck → 某路 LDO → WiFi 模组。这里 LDO 的输入来自 buckbuck 的输入来自电池。这种关系在 regulator framework 里用vin-supply或者parent-supply表示。级联带来的直接后果是使能顺序要开 LDO得先保证 buck 是开的要关 buck得先确认 LDO 已经关了。core 通过supply指针把 regulator 串成一棵树在 enable/disable 时递归处理。这也是为什么第 1 章那个 WiFi 上电时序问题加上vin-supply之后就好了——框架会自动保证父节点先于子节点上电。3. 核心数据结构与关键流程3.1 三个必须记住的结构体看内核代码第一步永远是搞清楚核心数据结构。regulator 里最关键的是这三个struct regulator_desc描述一路 regulator 的静态属性比如名字、支持的电压表、ops 指针、regmap 等。它是 provider 驱动里静态定义的通常一个数组对应一颗 PMIC 的所有输出。struct regulator_dev运行时实例由 core 在regulator_register时创建。它把regulator_desc和具体的硬件上下文比如 regmap、GPIO绑定起来代表板子上真实存在的一路电。struct regulatorconsumer 拿到的句柄。注意它和regulator_dev不是一回事——一个regulator_dev可以被多个 consumer 引用每个 consumer 拿到一个独立的struct regulator各自维护自己的enable_count。用一句话概括三者关系regulator_desc是图纸regulator_dev是造好的实物struct regulator是用户手里的遥控器。3.2 provider 注册流程provider 驱动的 probe 里最终都会调用devm_regulator_register()。这个函数做的事情大致是分配并初始化regulator_dev。解析设备树里的 constraints填充regulation_constraints。如果配置了supply_name递归解析父节点建立 supply 链。把regulator_dev挂到全局链表regulator_list上。在 sysfs 下创建对应的目录和属性文件。这里有个细节值得说注册顺序和 supply 解析是解耦的。也就是说即使父 regulator 还没注册子 regulator 也能先注册core 会用一个regulator_supply_alias或者延迟解析的机制来处理。这个设计是为了应对驱动加载顺序不确定的现实问题——内核启动时谁先 probe 是不保证的。3.3 consumer 获取句柄的两种方式consumer 拿句柄有两种典型写法/* 方式一按名字获取名字来自设备树或板级配置 */ struct regulator *vdd; vdd devm_regulator_get(dev, vdd); if (IS_ERR(vdd)) return PTR_ERR(vdd); /* 方式二获取某路电的 dummy 句柄用于可选供电 */ vdd devm_regulator_get_optional(dev, vdd); if (IS_ERR(vdd)) { if (PTR_ERR(vdd) -ENODEV) vdd NULL; /* 这路电不存在走降级逻辑 */ else return PTR_ERR(vdd); }devm_前缀意味着资源由设备管理驱动卸载时自动释放不用手动regulator_put。这是现代内核驱动推荐的做法能省掉一大堆错误处理路径。regulator_get和regulator_get_optional的区别很关键前者如果找不到对应的 regulator 会返回-ENODEV并打印警告后者则允许这路电本来就不存在。什么时候用 optional比如某个外设的供电在 A 板上有、B 板上没有驱动要能兼容两种板子这时候就得用 optional。3.4 enable/disable 的完整路径以regulator_enable为例core 里的处理路径大致是检查regulator句柄是否合法。如果enable_count从 0 变 1说明是第一次真正使能继续往下。检查 constraints 里是否允许 enablevalid_ops_mask。如果这路电有 supply 父节点先递归 enable 父节点。调用 provider 的ops-enable()操作硬件。更新状态enable_count。disable 是反过来的先减计数减到 0 时先关自己再递归关父节点如果父节点也没人用了。实操心得调试 enable 相关问题时/sys/kernel/debug/regulator/regulator_summary是最有用的工具。它会打印出每一路电的名字、当前状态、enable_count、电压、以及谁在用它。我排查某路电莫名其妙被关掉的问题第一步永远是看这个文件。4. 设备树配置与实操要点4.1 一个完整的 PMIC 设备树片段设备树是 regulator 配置的主战场。下面是一个简化但完整的例子展示一颗虚构 PMIC 的三路输出i2c1 { pmic: pmic58 { compatible vendor,fake-pmic; reg 0x58; regulators { compatible simple-bus; #address-cells 1; #size-cells 0; buck1: buck1 { regulator-name vdd_cpu; regulator-min-microvolt 800000; regulator-max-microvolt 1300000; regulator-always-on; regulator-boot-on; regulator-ramp-delay 10000; }; ldo1: ldo1 { regulator-name vdd_wifi; regulator-min-microvolt 1800000; regulator-max-microvolt 1800000; vin-supply buck1; regulator-boot-on; }; ldo2: ldo2 { regulator-name vdd_sd; regulator-min-microvolt 3300000; regulator-max-microvolt 3300000; regulator-always-on; }; }; }; };这里有几个点值得展开regulator-name是这路电的标识consumer 通过它来匹配。名字要唯一否则regulator_get可能拿到错误的那一路。regulator-min/max-microvolt定义了电压范围。如果 min 和 max 相等说明这路电是固定电压core 会拒绝任何调压请求。regulator-ramp-delay是电压爬升延迟单位微伏每微秒或者微秒取决于具体 binding。这个参数在动态调压场景下非常重要如果设得太小硬件还没稳定软件就以为调好了会导致下游器件工作异常。vin-supply建立父子关系前面已经讲过它的作用。4.2 consumer 侧的设备树写法外设驱动要引用某路电在设备树里这样写mmc0 { vmmc-supply ldo2; vqmmc-supply ldo1; status okay; };驱动里用devm_regulator_get(dev, vmmc)就能拿到ldo2。注意属性名vmmc-supply去掉-supply后缀就是 consumer 里用的名字这是内核约定的命名规则。4.3 电压选择的计算过程假设某路电支持一组离散电压provider 的ops-list_voltage会返回一个电压表。consumer 调用regulator_set_voltage(vdd, 1200000, 1200000)时core 会检查 1200000 是否在 constraints 的[min_uV, max_uV]范围内。调用ops-list_voltage遍历支持的电压找到最接近且不超过请求值的档位。如果找到的档位和当前档位相同直接返回不做硬件操作省时间。否则调用ops-set_voltage写寄存器然后按ramp-delay等待稳定。这里有个容易踩的坑如果请求的电压在支持的档位里找不到精确匹配core 会选一个最接近但不超过的值。比如你请求 1.25V但硬件只支持 1.2V 和 1.3V那实际会设成 1.2V。如果你的器件要求至少 1.25V就会出问题。所以配置时一定要确认硬件支持的档位和你的需求匹配。4.4 实操现场用 sysfs 验证配置配置完设备树编译烧录之后第一件事是验证 regulator 有没有正确注册。方法很简单# 查看所有已注册的 regulator ls /sys/class/regulator/ # 查看某一路的详细信息 cat /sys/class/regulator/regulator.1/name cat /sys/class/regulator/regulator.1/state cat /sys/class/regulator/regulator.1/microvolts cat /sys/class/regulator/regulator.1/num_usersstate会显示enabled或disablednum_users就是当前的 enable_count。如果某路电你期望是开的但显示 disabled或者 num_users 是 0那就要回去查设备树和驱动了。更详细的信息在 debugfs 里mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/regulator/regulator_summary这个文件会以树状结构打印所有 regulator包括它们的 supply 关系、电压、状态、以及每个 consumer 的引用情况。我强烈建议把它加入你的调试工具箱比翻代码快得多。5. 常见问题与排查技巧实录5.1 问题速查表我把这些年遇到过的 regulator 相关问题整理成一张表按现象分类现象可能原因排查方向驱动 probe 返回 -EPROBE_DEFERprovider 还没注册检查 provider 驱动加载顺序、compatible 是否匹配regulator_get 返回 -ENODEV设备树里没配 supply检查xxx-supply属性名拼写电压设置不生效constraints 范围限制看 dmesg 是否有 not supported 警告某路电被意外关闭引用计数不平衡看 regulator_summary 的 num_users上电时序错误缺 vin-supply 或 boot-on补父子关系和启动约束调压后系统不稳定ramp-delay 太小增大 ramp-delay 或加延时5.2 典型翻车案例引用计数泄漏前面提到过引用计数这里讲一个我亲身踩的坑。某次写一个传感器驱动probe 里regulator_enable了但错误处理路径里忘了regulator_disable。结果传感器 probe 失败重试几次之后那路电的 enable_count 一直是正数永远关不掉整机待机功耗高了 20mA。排查方法就是看regulator_summary发现某路电的 num_users 比预期多。定位到具体驱动后把错误路径补全就好了。经验教训用devm_regulator_get拿句柄但 enable/disable 的配对还是要自己保证devm 只管句柄释放不管计数平衡。5.3 典型翻车案例EPROBE_DEFER 死循环另一个常见问题是-EPROBE_DEFER。当 consumer 驱动比 provider 驱动先 probe 时regulator_get会返回-EPROBE_DEFERconsumer 驱动应该返回这个错误让内核稍后重试。但如果 provider 驱动因为某种原因一直注册失败consumer 就会无限重试dmesg 里刷屏。排查思路先确认 provider 驱动有没有加载lsmod或者看/sys/bus/i2c/devices/。看 provider 的 probe 有没有报错常见的是 I2C 通信失败或者 regmap 配置错误。确认设备树里 provider 节点的status是okay。提示如果 provider 是 built-in 而 consumer 是模块或者反过来加载顺序会不一样。生产环境建议把相关的 regulator 驱动都编进内核减少 probe 顺序问题。5.4 独家避坑技巧最后分享几个文档里不太会写、但实际很有用的技巧技巧一用regulator-always-on要谨慎。它确实能避免电被误关的问题但也会掩盖引用计数不平衡的 bug。调试阶段建议先不加等问题暴露出来再决定是否真的需要 always-on。技巧二regulator-boot-on和regulator-always-on不是一回事。boot-on 只保证启动时使能一次之后可以被关always-on 是永久使能。很多人混用这两个导致行为不符合预期。技巧三调压前先regulator_get_voltage读一下当前值。有些 PMIC 的调压操作有副作用比如会短暂掉电如果目标值和当前值一样就没必要调。core 虽然做了这个优化但自己心里有数更稳妥。技巧四多路电共用同一个 GPIO 使能时注意 provider 的enable实现。有些简单的 GPIO regulator 不支持引用计数需要确认ops里有没有正确处理。技巧五调试早期上电问题时可以在 U-Boot 里先把关键电打开。内核起来之前的那段时间regulator framework 还没工作如果器件需要早期供电得靠 bootloader 兜底。6. 从框架到实战的几点体会regulator framework 这套代码我前前后后读了好几遍每次都有新收获。它最值得学习的地方不是某个具体的 API而是它如何用一套抽象把硬件差异和使用需求隔离开。provider 驱动只关心寄存器consumer 驱动只关心电压和开关中间的约束校验、引用计数、级联管理全部由 core 统一处理。这种设计思路放到任何一个需要管理共享资源的子系统里都适用。如果你正在做 BSP 或者写外设驱动我的建议是不要满足于照着别人的设备树抄一遍能跑就行。花点时间把regulator_summary看懂把每一路电的 supply 关系画出来把每个 consumer 的 enable/disable 配对检查一遍。这些工作看起来琐碎但能帮你避开 90% 的功耗和上电问题。至于后续可以深入的方向一个是regulator和runtime pm的配合——设备进入 runtime suspend 时自动关电这是低功耗设计的核心另一个是动态电压频率调节DVFS里 regulator 扮演的角色cpufreq调频时同步调压这部分和 regulator 的交互非常紧密。这两个话题展开又是很长的内容有机会再单独聊。