一文讲透 Type-C 快充驱动原理
很多人第一次接触 Type-C 快充驱动时，容易把注意力放在“电压怎么升到 9V、12V、20V”上。其实在驱动视角里，快充不是简单把电压拉高，而是一套非常谨慎的工程流程：先确认对端是谁，再确认双方能承受什么功率，最后才让电源路径真正切换。
如果把普通 USB 供电视为“插上就给默认电流”，那 Type-C 快充更像一次带安全条款的供电谈判。接口、协议芯片、内核驱动、充电 IC、温控和保护逻辑都要参与。任何一个环节理解错，结果可能不是充电慢，而是反复断连、协商失败、充电发热，甚至触发硬件保护。
一、Type-C 快充先看整体链路
Type-C 快充系统大致可以拆成五层：接口识别、协议协商、驱动状态机、功率路径控制、调试保护。它们不是并列堆在一起的功能点，而是一条从物理连接到系统决策的链路。
接口层负责回答一个最基础的问题：线插上了吗，对端是供电端还是受电端？这一步主要依赖 CC1/CC2 引脚。协议层继续回答：对方能提供哪些电压电流组合，本机想申请哪一档？驱动层把这些事件变成内核里的状态变化，再通知电源框架和充电管理模块。功率层才真正去改 PMIC、charger 或 buck/boost 的工作状态。
所以，Type-C 快充驱动真正要做的事不是“制造电压”，而是让系统在正确时机做正确决策。它要把硬件事件翻译成软件状态，把协议消息翻译成电源策略，把异常条件翻译成保护动作。
1.1 为什么不能插上就升压
高压快充最怕盲目执行。假设设备端还没有确认线缆能力、对端能力和本机输入限制，直接把 VBUS 拉到高电压，就可能遇到三个问题：
对端不是支持 PD 的充电器，只能维持默认 5V。 线缆或接口状态异常，无法承受目标电流。 系统温度、电池状态或 PMIC 限制不允许进入高功率。
因此 Type-C 快充一定是“识别在前，协商在中，执行在后”。驱动的价值就在于把这个顺序守住。
二、从插入到协商：快充是先谈合同
Type-C 接口里最关键的两根信号线是 CC1 和 CC2。设备通过检测 CC 上的电阻关系，判断插头方向、连接状态和供受电角色。比如手机作为受电端时，会通过 Rd 表明自己需要供电；充电器作为供电端时，会通过 Rp 表明自己可以提供电流。
完成基本识别后，普通 Type-C 可以先进入默认供电能力。但要进入更高功率，就需要 USB PD 协议参与。PD 协商可以理解为双方在 CC 线上交换“供电合同”：
供电端发布能力列表，也就是 Source Capabilities。 每个能力档位通常可理解为 PDO，比如 5V/3A、9V/3A、12V/2.25A。 受电端选择一个自己能接受的档位，发送 RDO 请求。 供电端确认后，双方建立供电合约。
这里最容易误解的是，PDO 不是驱动随便写一个高电压就能生效。它必须来自供电端真实声明的能力，也要受设备端电池、温度、充电 IC 和系统策略限制。驱动可以选择目标，但不能无视硬件边界。
2.1 驱动状态机为什么重要
PD 协议本身是事件驱动的。插入、拔出、能力变化、请求成功、请求拒绝、硬复位、软复位、过流、过温，都可能改变当前状态。驱动如果只处理“成功协商”这一条路径，实际产品里很快就会翻车。
一个可维护的 Type-C 快充驱动，通常会把关键状态拆清楚：
未连接：等待 CC 检测。 已连接：确认角色和默认电流。 协商中：等待 Source Capabilities、发送 Request。 合约建立：通知电源框架和充电模块。 异常恢复：降额、重试、断开或回到默认 5V。
这个状态机的好处是，每个外部事件都有明确入口，每个保护动作都有明确出口。调试时也能从日志里看出系统卡在哪一步。
三、驱动如何落地：它是协议和电源的翻译官
在 Linux 或类 Linux 系统里，Type-C 快充驱动通常不会单独完成所有事。它更像一个中间层：下面对接 PD 控制器、PMIC、charger；上面对接 typec、tcpm、power_supply、thermal 等框架。
硬件上，PD 控制器可能通过 I2C 或 SPI 暴露寄存器，中断脚负责通知事件。设备树里会描述总线地址、中断 GPIO、角色策略、供电路径、最大电流和相关 regulator。驱动 probe 成功后，先初始化芯片，再注册系统可见的 Type-C 端口和电源能力。
协商事件到来时，驱动会读取控制器状态，解析当前电压电流能力，再更新内部状态机。如果合约建立成功，它不会直接“想当然”地打开高功率，而是通知 power_supply 或 charger 框架，让真正掌握硬件功率路径的模块执行。
3.1 一个简化的驱动处理模型
下面这段伪代码只保留核心逻辑，重点看事件如何被翻译成电源策略：
●●●enum tc_state {
TC_DISCONNECTED,
TC_ATTACHED,
TC_NEGOTIATING,
TC_CONTRACT_READY,
TC_FAULT,
};
void pd_irq_worker(struct tc_port *port)
{
int event = pd_read_event(port); // 从 PD 控制器读取本次中断事件
if (event == PD_EVT_DETACH) {
port->state = TC_DISCONNECTED; // 拔出后回到未连接状态
charger_set_input_limit(500); // 先恢复到保守输入限制
return;
}
if (event == PD_EVT_SOURCE_CAP) {
struct pdo best = choose_safe_pdo(port); // 按电池、温度和硬件能力选择档位
port->state = TC_NEGOTIATING; // 进入协商状态
pd_send_request(port, best); // 发送 RDO 请求
return;
}
if (event == PD_EVT_CONTRACT_OK) {
port->state = TC_CONTRACT_READY; // 合约建立完成
power_supply_changed(port->psy); // 通知系统更新充电能力
charger_apply_pd_contract(port); // 让 charger/PMIC 执行功率路径切换
return;
}
if (event == PD_EVT_FAULT) {
port->state = TC_FAULT; // 异常状态要显式记录
charger_fallback_to_5v(port); // 降级到安全供电
}
}这段逻辑背后的原则很简单：PD 控制器负责告诉你发生了什么，驱动负责判断这件事意味着什么，charger/PMIC 负责把决策变成真实电流路径。边界分清，问题才好查。
3.2 设备树不是摆设
很多快充问题最后会查到设备树或板级配置。比如中断触发沿写错，驱动收不到插拔事件；最大输入电流配置过保守，协商到了 9V 也跑不上功率；相关 regulator 没有正确声明，导致功率路径切换失败。
设备树至少要把三类信息说清：
控制器怎么访问：I2C/SPI 地址、中断 GPIO、复位脚。 端口怎么工作：Source、Sink、DRP，是否支持角色切换。 电源怎么执行：charger、PMIC、VBUS regulator、最大电压电流限制。
这些配置看起来琐碎，但它们决定驱动能不能把协议结果落到硬件动作。
四、调试与保护闭环：稳定快充不是一次点亮
快充驱动调试最忌讳只看“有没有充上”。真正可靠的验证要形成闭环：复现问题、抓事件、看协议、测电气、分类异常、执行保护、做回归。因为 Type-C 快充涉及协议和电源两个世界，只看软件日志或只看电压表都不够。
常见调试入口包括：
dmesg：确认插拔、中断、状态机迁移、错误码。 trace 或 debugfs：确认 tcpm/typec/power_supply 的通知链路。 PD 抓包器：确认 Source Capabilities、Request、Accept、PS_RDY 是否完整。 USB 电流表或示波器：确认 VBUS 是否按预期变化，是否有跌落和抖动。 温度和电池日志：确认系统有没有主动降额。
4.1 先把失败分清楚
“快充失败”只是现象，不是结论。工程上要先分类：
没识别：CC 检测、插头方向、线缆、接口焊接优先排查。 没协商：PD 消息、控制器固件、中断、状态机优先排查。 协商成功但功率低：电池策略、温控、charger 限流、线损优先排查。 运行中掉回 5V：过流、过温、VBUS 跌落、兼容性重试优先排查。 反复断连：硬复位、软复位、异常恢复路径和 debounce 优先排查。
分清阶段后，排查效率会高很多。否则日志里每一行都像线索，最后反而抓不住主因。
4.2 保护逻辑要宁可保守
快充驱动不是跑分工具。产品里宁可慢一点，也不能在异常条件下硬撑高功率。过流、过温、线缆不稳定、协议超时、对端行为异常时，驱动应该有明确的降级策略：回到 5V、降低输入电流、重新协商、延迟重试或断开路径。
一个好用的保护策略通常有三个特点：
可解释：日志能说明为什么降级。 可恢复：异常解除后能重新进入合理状态。 可限制：不会无限重试，也不会在故障中来回振荡。
这也是快充驱动从“能跑”走向“可量产”的分水岭。
五、写 Type-C 快充驱动的工程建议
如果从零开始做一个 Type-C 快充项目，建议按下面顺序推进，而不是一上来就调最高功率：
先验证 5V 默认供电和插拔事件，确认 CC 检测稳定。 再验证 PD 消息收发，确认 PDO/RDO 和合约建立路径。 接着联调 charger/PMIC，确认电压电流真的按策略执行。 然后加入, 温控、电池状态、线缆能力和异常降级。 最后做兼容性和压力测试，包括不同充电器、不同线缆、热插拔、低电量、高温、满电等场景。
代码结构上，建议把协议事件、状态机、电源策略、硬件执行分层，不要把所有判断塞进一个中断函数。日志也要围绕状态机设计：每次状态变化、每次协商请求、每次功率切换、每次保护动作，都应该能查到原因。
Type-C 快充驱动的难点不在某个寄存器，而在跨层协作。CC 检测决定能不能开始谈，PD 协议决定能谈什么，驱动状态机决定什么时候谈，电源框架决定怎么执行，保护策略决定异常时怎么收场。把这条链路看清楚，再回头看代码和日志，很多问题就不再神秘。
六、总结
通俗地说，Type-C 快充不是“插上就猛充”，而是一次受约束的供电协商。驱动的核心价值，是把接口状态、协议消息和硬件能力组织成稳定的决策流程。
做得好的快充驱动，既能把高功率跑起来，也能在异常时退得稳、恢复得清楚、日志查得明白。真正的工程质量，往往就体现在这些看似不显眼的边界条件里。
|
||||||||||||||||||||||||
 |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
