简介Hi6421电源管理集成电路核心驱动源文件面向嵌入式驱动开发工程师与电源管理学习者用于理解PMIC驱动初始化、总线通信、功耗控制及保护机制的具体实现。压缩包内仅含1个C语言文件hi6421-pmic-core.c体积约1KB虽是精简源码却涵盖驱动框架中初始化、控制、中断与故障检测等典型模块适合作为阅读与二次开发的入手点。目前已有457人学习下载。通过研读该驱动可掌握Hi6421经I2C/SPI与主处理器交互的方式理解动态电压频率调整、低功耗模式切换以及过压欠压保护策略的代码写法同时为自行移植和裁剪PMIC驱动提供参考。该源文件浓缩了驱动核心逻辑从代码层面呈现寄存器配置、事件处理与状态监控的细节有助于快速建立PMIC驱动开发的基本框架。1. 为什么先看 hi6421-pmic-core.c再看数据手册搞嵌入式电源管理时最烦的不是驱动写不出来而是 PMIC 在总线上没有反应I2C 探测不到、调节器注册后电压不准、休眠后唤不醒。Hi6421 这类 PMIC 的驱动通常拆成 core 层和 regulator 层hi6421-pmic-core.c正是负责初始化、regmap 绑定和维护中断事件分发的那一层。理解了它你就能说清驱动向内核暴露了几路电源、每路用什么寄存器控制、中断状态从哪里读也就能在 PMIC 不带负载也能把电压值读到怀疑人生的时候知道问题出在哪一段链路。它面向的是负责系统 bring-up 的驱动工程师也适合做硬件电源设计的人反向核对供电方案因为驱动里的位域定义就是芯片行为的另一种描述形式。2. I2C 通信层与寄存器操作driver 与 Hi6421 的第一次握手2.1 先确认主控接口和寄存器映射Hi6421 在便携设备的典型接法是把 I2C 总线挂在主控的电源管理域下面两根信号线拉上拉电阻后直接连 SOC 的 I2C 控制器中断脚单独走一个 GPIO。驱动与芯片的第一次握手是 regmap 注册regmap 负责把 Linux 的寄存器读写抽象成可配置的读写回调后续的 regulator 操作全部走 regmap而不是直接调i2c_transfer。硬件上如果 I2C 地址和上拉不对regmap 初始化本身不会失败但第一次读寄存器会返回-EIO这个信号在 bring-up 阶段比任何日志都值得优先抓。写驱动之前先确认regmap_config的寄存器位宽和地址位宽。固定的配置会这样放static const struct regmap_config hi6421_pmic_regmap_config { .reg_bits 8, .val_bits 8, .max_register 0xff, .name hi6421-pmic-core, };这里把寄存器地址和寄存器值都按 8 位处理max_register 0xff表示寄存器空间最多到 256 个字节这是很多 PMIC 控制寄存器的典型跨度。name字段在调试时会显示在 trace 和 sysfs 里所以不要把名字写成空字符串方便后续在/sys/kernel/debug/regmap下查找对应节点。如果实际芯片使用 16 位寄存器地址就必须改reg_bits 16否则后续所有读写都会出现地址偏移表现是读出来的电压值偶尔正常、偶尔跳变非常难定位。2.2 regmap 的读写回调怎么挂进 core 层hi6421-pmic-core.c这一个文件不会承载所有功能它要完成的是把底层资源准备好再让子驱动去注册 regulator。代码里常见的一段 probe 逻辑是这样static int hi6421_pmic_probe(struct i2c_client *i2c) { struct device *dev i2c-dev; struct regmap *regmap; regmap devm_regmap_init_i2c(i2c, hi6421_pmic_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); /* core 层只负责基础资源和中断调节器注册交给子驱动 */ return hi6421_pmic_core_init(dev, regmap); }devm_regmap_init_i2c会把这个 regmap 的生命周期绑定到 I2C 设备的 device 对象上probe 失败或设备注销时自动释放。hi6421_pmic_core_init里通常会读取一个芯片 ID 寄存器确认硬件版本然后申请中断。这个阶段要注意 I2C 总线可能被多个外设共享PMIC 的寄存器读写在 DVFS 期间会变得频繁所以 regmap 层的缓存能力很重要。如果硬件接口允许尽量把cache_type设为REGCACHE_RBTREE减少实际总线事务。内核里 regmap cache 需要和芯片供电域初始化顺序配合不要在 PMIC 时钟或使能脚未准备好的时候去读寄存器否则会读到全0xff或全0x00这两种值一样都是无效状态。常见做法是先用手册里的 reset value 初始化reg_defaults数组这样即使 I2C 回读异常驱动也能区分是通信错误还是芯片仍在复位中。2.3 寄存器位域与电压换算的常见坑读取 PMIC 寄存器时只关心位域更安全。下面的函数是典型的电压选择器读取static int hi6421_get_voltage_sel(struct regulator_dev *rdev) { unsigned int val; int ret; ret regmap_read(rdev-regmap, HI6421_LDO_VSET_REG, val); if (ret) return ret; return (val HI6421_LDO_VSET_MASK) HI6421_LDO_VSET_SHIFT; }这里HI6421_LDO_VSET_MASK和HI6421_LDO_VSET_SHIFT来自 hi6421 数据手册里的位域描述。一个 LDO 的电压选择位可能只有 3 位但寄存器顶部的保留位和高位控制位如果不做 mask直接参与运算会得到错误的 selector进而让 regulator framework 输出一个完全不在预期范围内的电压。这类问题在板级调试里非常隐蔽因为代码看起来读到了寄存器实际上把保留位的随机值也算进去了。常见位域配置可以整理成下面的表格实际数值必须与芯片型号对应位域功能典型配置Bit7LDO 使能1 开启0 关闭Bit6:4工作模式自动/强制 PWMBit3:0电压选择对应 VSET 表改变电压时用regmap_update_bits比regmap_write安全因为它只翻转目标 bit不会动到同一寄存器里的使能位。有人会把regmap_update_bits和regmap_set_bits混用后者只做置位操作遇到要先清掉旧值再置新值的场景就会出错LDO 输出可能短暂跳到中间档位对 CPU 核心供电来说这足以触发一次异常复位。提示遇到电压误跳变先查set_voltage_sel里使用的是 update 还是 write再查 mask 是否覆盖了全部控制位。3. probe 顺序、中断与故障保护让驱动在异常时先于硬件损伤反应3.1 调节器的注册要等 core 初始化完成Hi6421 的驱动结构和多数 PMIC 驱动一样分为 core 和功能两层。core 层把 regmap、IRQ、系统休眠回调准备好再让各个 LDO/BUCK 子驱动去注册 regulator这样每个子驱动不需要重复 I2C 初始化和中断申请。hi6421-pmic-core.c的文件名已经说明它是“核心”而不是完整平台驱动你在实际开发中还需要在同一个目录下实现hi6421-regulator.c来填写控制回调。static const struct regulator_ops hi6421_ldo_ops { .set_voltage_sel hi6421_set_voltage_sel, .get_voltage_sel hi6421_get_voltage_sel, .enable hi6421_enable, .disable hi6421_disable, .is_enabled hi6421_is_enabled, };这个 ops 表说明该 LDO 以电压选择器方式工作内核会把regulator_set_voltage传下来的目标电压转换成 selector再调用set_voltage_sel。驱动需要保证设备树里的regulator-min-microvolt和regulator-max-microvolt与线性表对齐如果芯片电压表不是线性的还要改写list_voltage回调返回查表结果。寄存器里如果写了超出位域范围的值PMIC 的行为往往不是拒绝而是跳到一个意想不到的保护电压所以驱动里要对 selector 做边界检查。3.2 中断状态寄存器读一遍就要清掉PMIC 的中断不像普通外设可以靠内核自动 mask它需要驱动主动读状态寄存器并写“清中断”位。如果只读不写同一个中断会反复触发导致系统不断进入 handlerCPU 占用率看起来会被某个 kworker 占满。hi6421 会把多种事件合并在同一个中断引脚上复用一个 IRQ number再由驱动在中断线程里通过寄存器区分事件来源。static irqreturn_t hi6421_irq_thread(int irq, void *data) { struct hi6421 *pmic data; unsigned int irq_status; regmap_read(pmic-regmap, HI6421_IRQ_STATUS0, irq_status); if (irq_status HI6421_IRQ_OVP) { regulator_notifier_call_chain(pmic-rdev, REGULATOR_EVENT_OVER_VOLTAGE, NULL); } if (irq_status HI6421_IRQ_UVP) { regulator_notifier_call_chain(pmic-rdev, REGULATOR_EVENT_UNDER_VOLTAGE, NULL); } regmap_write(pmic-regmap, HI6421_IRQ_ACK0, irq_status); return IRQ_HANDLED; }中断线程里先用regmap_read读出状态再按位判断事件类型通过regulator_notifier_call_chain通知上层。这里regmap_read和regmap_write都是可睡眠的所以不能用普通 hardirq handler必须注册为IRQF_ONESHOT的线程化中断。最后回写HI6421_IRQ_ACK0是必须的否则 PMIC 会认为驱动没有处理完事件中断线一直被拉低后续所有新事件都看不到。3.3 常用保护阈值与恢复机制Hi6421 的保护机制通常有硬件和软件两层硬件层可以在驱动完全失效时直接关输出软件层负责把事件转成内核可感知的信号。驱动要做的不是阻止芯片关输出而是记录异常路径、判断是否可以自动恢复以及在反复触发时避免无限重试。下面是一组常见事件的驱动处理习惯事件硬件行为驱动动作恢复条件过压输出钳位或关闭发送 OVER_VOLTAGE 通知电压回落到阈值以下欠压输出关闭通知上层降载或复位输入电压恢复后重新 enable过流输出限流记录状态并延迟重试外部短路解除后 release过温全系统热关断进入 thermal shutdown温度降到回滞点以下实际设备上我一般会这样设计恢复流程收到OVER_CURRENT后先记录日志不立即重启延迟 100 到 500 毫秒重新 enable因为瞬时浪涌可能已经过去重试三次仍然失败就标记该 regulator 为失败并通知系统进入低功耗模式。这里的 debounce 时间不能太长太长屏幕电源会闪烁也不能太短太短输出电容放电不充分再次 enable 会带着过压风险。最好对照数据手册里的 recovery time 参数比拍脑袋定的毫秒数可靠得多。注意恢复流程最好放在 workqueue 或 delayed_work 里不要在中断线程里直接msleep否则会阻塞后续所有 PMIC 中断事件的处理。4. DVFS 与低功耗模式从 set_voltage 到挂起电源域4.1 selector 换算让 DVFS 切换更短DVFS 在驱动层主要处理两件事把目标电压写到 VSET 寄存器以及在 CPU 进入低功耗时切换电源模式。Hi6421 的驱动中关键路径是set_voltage_sel回调用总线写入电压选择位电压上升斜率由 PMIC 硬件决定软件只负责保证目标 selector 正确。static int hi6421_set_voltage_sel(struct regulator_dev *rdev, unsigned int sel) { return regmap_update_bits(rdev-regmap, HI6421_LDO_VSET_REG, HI6421_LDO_VSET_MASK, sel HI6421_LDO_VSET_SHIFT); }这里的sel HI6421_LDO_VSET_SHIFT会先被 CPU 计算成目标位域值再与 mask 配合写入。内核要求这个函数尽量快所以不要在读改写之间加msleep。如果硬件要求写入后等待电压稳定正确做法是把等待时间放到set_voltage_time_sel回调里由 regulator framework 统一管理延迟这样 DVFS 切换时可以并行处理多个 regulator而不是串行阻塞。一个常见的电压域参数表如下设计设备树时需要按这个范围去约束电源域最小电压最大电压选择位宽VDD_CPU0.8V1.1V5 bitVDD_MEM1.1V1.3V4 bitVDD_IO1.8V3.3V6 bit设备树里写的电压范围如果比这个宽框架换算出的 selector 可能超出寄存器位域。驱动在set_voltage_sel里做一次if (sel max_sel) return -EINVAL;会省去很多晚上加班追 bug 的时间。4.2 低功耗模式配置休眠时如何关闭未用 rails低功耗模式不只是用户在 shell 里跑个echo mem /sys/power/state还需要驱动通过 regulator framework 的 suspend 状态管理提前声明哪些 rail 可以关闭。设备树中定义某个 LDO 在系统挂起时关断比应用层手动操作更可靠因为它不依赖用户空间服务是否在运行。hi6421_pmic { ldo2 { regulator-min-microvolt 1800000; regulator-max-microvolt 1800000; regulator-state-mem { regulator-off-in-suspend; }; }; };这段配置表示系统进入state-mem时 LDO2 关闭恢复后自动回到正常电压。内核会在regulator_suspend_prepare阶段遍历所有 regulator 节点的regulator-state-*子节点按照依赖关系决定关断顺序。相比在 suspend 前由用户空间写 sysfs用 devicetree 声明能保证每次都生效也不会因为 initramfs 阶段还没有设备节点而失败。4.3 热管理中驱动能做的部分PMIC 自身集成温度采样但驱动不能只在芯片触发 over temperature 中断后才响应。常见做法是让 thermal 框架周期性读取 PMIC 温度寄存器再结合系统 CPU 频率做降频节流。hi6421 的 core 层一般只暴露一个温度读取接口不直接实现控制算法。static int hi6421_get_temp(void *data, int *temp) { struct hi6421 *pmic data; unsigned int val; regmap_read(pmic-regmap, HI6421_TEMP_REG, val); *temp (val 0xff) * 1000; /* 单位 m°C */ return 0; }温度值的单位换算一定要以数据手册为准。同样一个 8 位寄存器可能是线性码也可能在不同温度区间有不同的斜率直接把斜率套到 85 度以上会导致保护延迟触发或误触发。建议在驱动里保留一个calibrate_offset用于处理芯片个体差异这个偏移可以在 bring-up 阶段通过 sysfs 临时调整。5. 调试技巧用 trace、sysfs 和 hi6421 PDF 数据手册对照位域5.1 开启 regulator tracepoint观察电压切换时序驱动写完不能只靠逻辑正确来证明要观察 DVFS 切换时是否真的把目标值写进 PMIC。不要直接在代码里加 printkprintk 的时序扰动在电压切换这种微秒级操作里会产生误判。更稳妥的做法是打开内核的 regulator tracepointtrace-cmd record -e regulator_set_voltage -e regulator_enable -e regulator_disable trace-cmd report regulator_trace.txt如果没有trace-cmd也可以直接读内核 trace 节点命令相同效果。拿到 trace 输出后以regulator为关键词过滤能看到哪个进程在什么时间请求了哪个电压值。如果发现目标电压和实际写入值不一致问题大概率在list_voltage或set_voltage_sel之间的换算逻辑而不是 I2C 通信。5.2 通过 sysfs 核对 regulator 状态系统启动后/sys/class/regulator目录会把每个注册的 regulator 列成regulator.X。核对某个 LDO 的状态用下面的命令cat /sys/class/regulator/regulator.3/name cat /sys/class/regulator/regulator.3/state cat /sys/class/regulator/regulator.3/min_microvolts cat /sys/class/regulator/regulator.3/max_microvolts如果state显示disabled但外部万用表量到仍有输出电压可能不是驱动没有关闭而是负载端存在大电容或者 PMIC 的 discharge 电阻没有打开。此时要检查驱动是否实现了set_discharge回调并在设备树里开启regulator-always-on或regulator-off-in-suspend之外的正确属性。两个电压边界值必须和预期一致否则 regulator framework 会主动缩小可用电压范围。5.3 打开 hi6421 PDF 配合 i2cget 做位域核对hi6421-pmic-core.rar这类源码包通常不带完整数据手册但项目里若有一份hi6421.pdf调试时应该随时放在手边。核对寄存器时不要反复改代码编译先用 i2c-tools 在运行态读出寄存器再与 PDF 里的 reset value 做对比。i2cdetect -y 0 i2cget -y 0 0x6b 0x060x6b是 I2C 设备地址0x06是寄存器偏移。如果i2cget返回0x00或0xff先查 I2C 上拉和地址引脚不要急着改驱动。如果读到的值和 PDF 中的 reset value 不一致再检查是不是有其他驱动先写了这个寄存器。用i2cset写值时要注意它会整字节写入调试时应先i2cget读出当前值再按 PDF 里的 mask 组装出完整字节避免覆盖同寄存器中的使能位。最后保留一个实用技巧量产问题大多发生在 PMIC 寄存器回到默认值而驱动没有重新写入关键配置的瞬间。可以在 probe 之后增加一次regmap_register_patch把 PDF 里标记为 recommended 的关键寄存器批量写回替代逐个手写regmap_update_bits。patch 表的内容以原厂参考驱动和最新版数据手册为准不要直接复用旧平台的值。本文还有配套的精品资源点击获取