1. 电源域框架为什么值得单独拎出来讲Linux 内核的功耗管理子系统是个相当庞杂的体系时钟、稳压器、电源域、运行时电源管理、系统级休眠每一块都能单独写一本书。但如果你真正在 SoC 平台上做过功耗调试就会发现一个很现实的问题大部分功耗异常最后都会落到电源域上。某个模块关不掉、某路电漏电、休眠时某块区域还在偷偷耗电追根溯源往往不是驱动写错了而是电源域的关系没理清楚。电源域通用框架Generic Power Domain简称 GENPD就是内核为了解决这个问题抽象出来的一层。它要回答的核心问题是一个硬件模块的电源开关到底该由谁来控制、什么时候控制、按什么顺序控制。在没有 GENPD 之前每个平台各写各的代码散落在 mach 目录里复用性极差。GENPD 把这套逻辑统一成了框架让平台只需要描述我有哪些电源域、谁挂在谁下面、开关时要做哪些事剩下的时序编排交给框架处理。这篇文章面向的是已经对 Linux 设备模型、驱动probe流程有一定了解想深入功耗子系统的嵌入式开发者。如果你正在做 SoC 的电源管理移植或者被设备关不掉电这类问题折磨过那这篇梳理应该能帮你把 GENPD 的整体脉络理清楚。我会从设计思路讲到核心数据结构再到实际注册和使用的完整流程最后把常见的坑一个个摆出来。需要说明的是GENPD 的代码在内核里经历过多次重构不同版本差异不小。我这里主要基于较新的内核版本5.x 到 6.x 这个区间来讲涉及具体结构体字段时你手上的代码可能略有出入但整体设计思想是一致的。2. GENPD 的整体设计思路拆解2.1 从每个平台自己管到统一框架的演进逻辑早期 ARM 平台管理电源域的方式非常原始。以典型的 SoC 为例芯片里通常有一堆电源开关寄存器每个 bit 控制一个模块的上电和下电。平台代码里会硬编码一堆操作比如打开显示模块前先给它的电源域上电关闭时反过来。这些逻辑散落在板级文件里换个芯片就得重写一遍。这种做法的根本问题在于电源域之间的关系是硬件固有的拓扑结构不应该和具体驱动耦合在一起。一个 GPU 可能挂在某个顶层电源域下面而这个顶层电源域又依赖另一个always-on域。这种父子关系是芯片设计决定的跟 GPU 驱动本身没关系。把这种关系写死在驱动里既容易出错也无法复用。GENPD 的抽象思路很清晰把电源域本身抽象成一个设备struct generic_pm_domain把域和域之间的依赖抽象成父子关系把域和实际设备之间的归属抽象成设备链表。这样一来框架就掌握了完整的拓扑图可以在设备需要上电时自动沿着拓扑把该开的域都开起来顺序不会错。这里有个关键认知GENPD 管的是电源域这个逻辑实体不是具体的稳压器或时钟。真正操作硬件寄存器的是平台提供的回调函数GENPD 只负责在正确的时机调用它们。2.2 为什么用域而不是直接管设备你可能会问既然最终目的是控制设备的电源为什么不直接给每个设备一个开关非要中间加一层域原因在于硬件现实。一个电源域通常同时给多个设备供电这些设备共享同一个电源开关。如果每个设备都独立控制这个开关就会出现一个设备想关电、另一个设备还在用的情况直接冲突。有了域这一层框架可以做引用计数域被多少个设备使用只有当最后一个使用者释放后才真正断电。另一个原因是时序。有些域必须在另一个域之前上电这种依赖关系用域来表达最自然。设备级别的依赖往往没这么清晰而域级别的依赖是硬件手册里明确写着的。2.3 框架与平台代码的职责边界理解 GENPD 的一个关键是搞清楚谁负责什么。框架负责的是通用的编排逻辑引用计数、父子域的上电顺序、设备的挂载和卸载、运行时电源管理的联动。平台代码负责的是具体的硬件操作怎么打开一个域、怎么关闭、怎么判断域当前状态、有没有特殊的时序要求。这条边界划得很重要。我见过一些移植代码把本该平台做的事塞进框架回调里结果就是回调函数里一堆平台相关的判断完全失去了通用性。反过来也有人试图在平台代码里自己维护引用计数那就等于绕过了框架迟早出问题。3. 核心数据结构与关键机制解析3.1 generic_pm_domain 结构体到底装了什么struct generic_pm_domain是整个框架的核心。它继承自struct dev_pm_domain所以本质上它也是一个 PM domain。里面几个关键字段值得逐个说清楚。name是域的名字调试时全靠它区分起名要能一眼看出是哪个硬件模块。flags记录域的各种属性比如GENPD_FLAG_ALWAYS_ON表示这个域永远不能关GENPD_FLAG_IRQ_SAFE表示可以在中断上下文里操作。power_on和power_off是平台必须实现的两个回调框架在需要开关域时调用它们。states和state_count是较新版本引入的支持一个域有多个电源状态比如 retention、off 等不再是简单的开和关。parent和child_node用来维护域的层级关系master_links和slave_links则是设备与域之间、域与域之间的连接链表。device_count记录当前有多少设备挂在这个域上device_list是设备链表。这两个字段配合引用计数使用是判断域能否关闭的依据。struct generic_pm_domain { struct dev_pm_domain domain; struct list_head gpd_list_node; struct list_head parent_links; struct list_head child_links; struct list_head dev_list; struct dev_power_governor *gov; struct generic_pm_domain *parent; struct gpd_dev_ops dev_ops; ... unsigned int device_count; unsigned int state_count; ... int (*power_on)(struct generic_pm_domain *domain); int (*power_off)(struct generic_pm_domain *domain); };3.2 设备与域的绑定genpd_dev_pm_attach 做了什么设备要受某个域管理得先挂上去。这个过程通常发生在设备 probe 之前由genpd_dev_pm_attach完成。它会根据设备树里的power-domains属性找到对应的域然后建立连接。绑定的时候会做几件事把设备加入域的dev_list增加device_count设置设备的dev-pm_domain指针指向这个域。这样后续设备做运行时电源管理时框架就知道该找哪个域。注意绑定是有顺序的。如果设备树里写的域还没注册绑定会失败。所以域的注册必须在设备 probe 之前完成通常放在postcore_initcall或者更早的阶段。3.3 父子域的依赖关系怎么表达域之间的父子关系通过parent指针和连接链表维护。一个域可以有多个子域但通常只有一个父域。当子域需要上电时框架会先确保父域已经上电这就是依赖关系的体现。这种设计解决了一个经典问题某些模块的电源来自一个总开关总开关不开子模块开了也没用。有了父子关系框架自动处理顺序平台代码不用手动保证。3.4 引用计数与状态机域的开关不是简单的布尔值而是一个状态机配合引用计数。每个域维护自己的使用计数设备请求上电时计数加一释放时减一。只有计数归零域才真正断电。状态机则处理更复杂的情况比如域正在上电过程中又来了一个请求或者域处于中间状态时收到关闭请求。框架用genpd_lock保护这些状态转换避免竞态。4. 电源域的注册与使用实操4.1 平台侧如何定义一个电源域定义一个电源域最直接的方式是静态声明一个generic_pm_domain结构体填好名字、回调、标志位然后调用pm_genpd_init初始化。初始化时会设置默认的 governor、初始化各种链表、把域加入全局的gpd_list。static struct generic_pm_domain gpu_pd { .name gpu_pd, .power_on gpu_pd_on, .power_off gpu_pd_off, .flags GENPD_FLAG_IRQ_SAFE, }; static int __init gpu_pd_init(void) { return pm_genpd_init(gpu_pd, NULL, false); } postcore_initcall(gpu_pd_init);pm_genpd_init的第三个参数表示初始是否上电。如果传 false域初始是关闭的第一次有设备请求时才会上电。4.2 设备树里怎么描述域和设备的归属设备树里用power-domains属性把设备关联到域。域本身通常用一个简单的节点表示带#power-domain-cells属性。gpu_pd: power-domain0 { compatible vendor,gpu-pd; #power-domain-cells 0; }; gpu: gpuff000000 { compatible vendor,gpu; power-domains gpu_pd; ... };如果域需要参数比如指定某个状态#power-domain-cells就设成对应的数量设备引用时带上参数。4.3 上电和下电回调里该写什么power_on和power_off回调是平台代码的核心。里面通常要做几件事操作电源控制寄存器、等待电源稳定、可能还要处理相关的时钟或复位。static int gpu_pd_on(struct generic_pm_domain *domain) { u32 val; /* 置位电源开关 */ val readl(pd_base PD_CTRL); val | GPU_PD_BIT; writel(val, pd_base PD_CTRL); /* 等待电源稳定硬件手册要求至少 1us */ udelay(1); /* 检查状态位确认已上电 */ val readl(pd_base PD_STATUS); if (!(val GPU_PD_BIT)) return -ETIMEDOUT; return 0; }实操心得等待时间不要凭感觉写。硬件手册里通常有明确的电源稳定时间要求写短了会偶发失败写长了浪费启动时间。我一般会按手册值再留 20% 余量。4.4 运行时电源管理如何与域联动设备做运行时电源管理Runtime PM时pm_runtime_get_sync会触发域的上电pm_runtime_put会触发域的引用计数减一。这套联动是框架自动完成的前提是设备已经通过genpd_dev_pm_attach绑定到了域。联动过程中框架会调用 governor 来决定是否真的断电。默认的 governor 是simple_qos它会考虑延迟约束等因素。如果你的场景有特殊需求可以自定义 governor。5. 常见问题与排查技巧实录5.1 域关不掉电的几种典型原因域关不掉是最常见的问题。排查时我一般按这个顺序看先确认device_count是不是真的归零了有时候某个设备忘了pm_runtime_put计数一直不为零。再看有没有子域还开着父域要等所有子域关闭才能关。最后看 governor 是不是因为延迟约束拒绝了关闭请求。有个隐蔽的情况是设备绑定了域但驱动里没正确调用运行时电源管理接口导致框架认为设备还在使用。这种问题用pm_genpd_summary一看便知它会列出每个域的引用计数和状态。5.2 上电顺序错误导致的偶发失败上电顺序错误往往表现为偶发失败因为大部分时候时序碰巧对了。典型场景是子域先于父域上电或者某个依赖的时钟还没使能就去操作电源寄存器。排查这类问题可以在power_on回调里加打印看实际调用顺序是否符合预期。如果顺序不对检查设备树里的power-domains引用是否正确以及域的注册顺序有没有问题。5.3 中断上下文操作域的限制在中断上下文里操作电源域是有风险的因为power_on回调里可能有睡眠操作比如msleep。如果确实需要在中断里操作域必须设置GENPD_FLAG_IRQ_SAFE并且回调里只能用非睡眠的等待方式。我踩过的坑是在中断处理里调用pm_runtime_get结果因为回调里有mutex_lock直接报睡眠在原子上下文的警告。后来改成用工作队列延迟处理问题解决。5.4 调试手段与日志分析调试 GENPD 最有用的工具是pm_genpd_summary在 debugfs 的pm_genpd目录下。它会输出每个域的名字、状态、引用计数、挂载的设备列表。另一个是pm_runtime_status看设备的运行时状态。如果问题比较隐蔽可以打开CONFIG_PM_DEBUG和CONFIG_PM_ADVANCED_DEBUG会有更详细的日志。我一般还会在关键回调里加pr_debug配合动态调试开关需要时打开平时不影响性能。问题现象可能原因排查手段域无法关闭设备引用计数未归零查看 pm_genpd_summary 的 device_count上电偶发失败时序或依赖顺序错误回调加打印核对硬件手册时序中断中操作报错回调含睡眠操作检查是否设置 IRQ_SAFE改用工作队列设备 probe 失败域未注册或绑定失败检查注册顺序和设备树引用5.5 性能与功耗的平衡取舍GENPD 的默认策略偏向省电域空闲就关。但有些场景下频繁开关域反而更耗电因为每次上电都有稳定时间和浪涌电流。这时候可以通过 governor 或者延迟约束来调整让域在一段时间内保持开启。我的经验是对于开关代价大的域比如带大电容的模拟模块设置一个合理的保持时间对于开关代价小的数字域让它随用随关。这个平衡点得靠实测功耗数据来定不能拍脑袋。6. 从 GENPD 看内核功耗框架的设计哲学GENPD 这套框架体现了一个很典型的内核设计思路把硬件固有的拓扑关系抽象出来用数据结构描述把变化的部分具体硬件操作留给平台回调。这样框架代码保持稳定平台代码只关注自己那块硬件。另一个值得琢磨的点是引用计数和状态机的配合。引用计数解决还有没有人用的问题状态机解决当前处于什么阶段的问题两者结合才能正确处理并发场景。这种模式在内核里反复出现理解了 GENPD再看其他子系统会轻松很多。实际做项目时我建议先把域的拓扑图画出来标清楚父子关系和每个域挂的设备然后再动手写代码。拓扑图清楚了代码结构自然就清晰调试时也有个参照。很多人上来就写回调写到一半发现关系没理清返工成本很高。最后分享一个我常用的调试技巧在pm_genpd_summary输出里如果看到某个域的引用计数长期不为零但又找不到是哪个设备占着可以逐个设备检查它的pm_runtime状态通常能揪出那个忘记释放的设备。这个笨办法虽然费点时间但比盲目猜测靠谱得多。