USB PD控制器驱动无法识别Type-C设备

Question

USB PD控制器驱动无法识别Type-C设备时，常见问题是由于固件未正确加载PD协议栈或CC引脚检测电路异常，导致控制器无法完成Type-C连接检测与电源角色协商。此外，驱动未适配特定厂商的PD芯片（如TI、ST、NXP等）或系统ACPI表配置错误，也会引发设备枚举失败。需检查驱动日志、确认I²C通信正常及DPM（Device Policy Manager）状态机是否卡滞。

Answer 1

1. 问题现象与初步定位

当USB PD控制器驱动无法识别Type-C设备时，最常见的表现是系统日志中无Type-C连接事件上报、电源协商失败或设备始终处于默认5V/500mA状态。这类问题通常发生在笔记本、移动设备或嵌入式主板的充电管理模块中。

初步排查应从以下三个维度入手：

• 固件是否成功加载PD协议栈（如USB PD 3.0规范）
• CC引脚检测电路是否存在硬件异常（如上拉/下拉电阻值错误、ESD损坏）
• 操作系统内核日志中是否有I²C通信超时或NACK响应记录

2. 深层技术分析路径

随着排查深入，需结合软硬件协同视角进行逐层剖析。以下是典型的故障树结构（FTA）分解：

1. 物理层失效：CC1/CC2线路开路、短路或滤波电容容值偏大导致信号上升沿迟缓
2. 通信链路异常：I²C总线地址冲突、SCL/SDA上拉不足或噪声干扰引发读写失败
3. 固件层面缺陷：PD协议栈未初始化、消息解码逻辑错误或超时重传机制缺失
4. 驱动兼容性问题：Linux内核中的tcpm或pd_chip_driver未适配TI TPS6598x、ST STUSB4500或NXP PTN5150等具体型号
5. ACPI表配置错误：_DSD方法中未正确声明PDO（Power Data Object）、RDO或缺失USB-PD-CAPABLE标识
6. DPM状态机卡滞：在src_attached_standby或snk_ready状态停滞，无法进入snk_transmit发送Request包

3. 关键诊断步骤与工具链支持

检查项	推荐工具	预期输出	常见异常
I²C连通性	i2cdetect -l / i2cget	显示PD芯片I²C地址（如0x2D for TPS65988）	No ACK, Device Busy
内核日志	dmesg | grep -i "tcpm\|pd"	"TCPM: CC detected: Rp-3.0A", "PD RX success"	"Failed to read revision", "DPM not started"
DPM状态机	通过debugfs读取/sys/kernel/debug/tcpm/<port>/state	显示当前状态如Sink Ready	Stuck in AttachWaitSink
ACPI解析	acpidump + iasl -d dsdt.dat	存在_PPC, _DSD包含USB PD相关UUID	Missing USBPD Capabilities UUID

4. 典型解决方案汇总

# 示例：强制重新加载PD控制器驱动（以Linux为例）
echo 1 > /sys/bus/i2c/devices/i2c-1/delete_device
sleep 1
echo tps65988 0x2d > /sys/bus/i2c/devices/i2c-1/new_device

# 查看DPM状态机流转情况
cat /sys/kernel/debug/tcpm/port0/state_machine
# 输出示例：
# State: SNK_READY
# Last Transition: 1678901234 ms
# Errors: 0 CRC, 2 Timeout

5. 高级调试流程图（Mermaid格式）

graph TD
    A[Type-C插入] --> B{CC引脚电压变化?}
    B -- 是 --> C[启动TCPC中断]
    B -- 否 --> Z[检查CC电路硬件]
    C --> D[I²C读取CC状态]
    D --> E{读取成功?}
    E -- 否 --> F[检查I²C总线]
    E -- 是 --> G[启动DPM状态机]
    G --> H{进入SNK_ATTACHED?}
    H -- 否 --> I[检查ACPI _DSD配置]
    H -- 是 --> J[发送PD Request]
    J --> K{收到Accept?}
    K -- 否 --> L[调整Voltage/Current请求]
    K -- 是 --> M[完成电源角色协商]