AUX通道基础概念与功能
1.1 AUX通道是什么
说白了，AUX通道就是DisplayPort接口里那条“悄悄话线路”。我刚开始接触DP的时候，总觉得主链路能传视频音频就够了，干嘛还要单独搞一条辅助通道？后来被一个EDID读取失败的问题折腾了两天，才明白AUX才是让源端和Sink端“正常对话”的关键。
AUX全称是Auxiliary Channel，全双工双向通信。它不传视频数据，只传控制信息和少量状态数据。你想想看，没有它，显示器怎么告诉显卡我支持什么分辨率？HDCP密钥怎么交换？DPCD寄存器谁来读写？
1.2 AUX物理层特性
物理层是我们排查问题最先遇到的地方。信号一旦有问题，上层再怎么写代码都白搭。我记得有一次客户反馈某批显示器间歇性黑屏，最后定位到AUX线缆上的共模噪声超标。
下面这张表总结了AUX物理层的核心参数，调试时经常需要对照：
| 参数 | 值 | 说明 |
|---|---|---|
| 信号类型 | 差分对 (D+/D-) | 与主链路类似，抗共模干扰 |
| 额定摆幅 | 340~1180 mV (峰值) | 标准1.2V摆幅，但实际视眼图而定 |
| 数据速率 | 2 Mbps (HBR/HBR2) 720 Mbps (HBR3) |
AUX速率跟随主链路速率变化 |
| 编码方式 | Manchester II | 自时钟，无单独的时钟线 |
| 最大线缆长度 | 15米（被动线缆） | 长距离需使用主动式或Retimer |
这里有个坑：Manchester编码的边沿密度高，对信号反射很敏感。我曾经遇到一个案子，PCB走线没做阻抗匹配，导致AUX眼图闭合，HDCP协商直接超时。所以，调试时别光盯着DPCD寄存器，先拿示波器看看AUX眼图。
1.3 AUX事务层操作
物理层通了，咱们再往上看事务层。AUX的事务层说白了就是一套I²C over AUX的封装协议。源端发起Request，Sink端回复Reply。每个事务包含一个Byte的命令头、20-bit的地址和若干数据段。
具体协议帧格式我列在下面，调试时用逻辑分析仪抓包看这结构最直观：
Command Byte: [7:4] Request Type (Read/Write/Native/...)
[3:0] Byte Count (0~15)
Address: 20-bit start address (DPCD或I²C)
Data: 0~16 bytes (根据Request Type)实际使用的请求类型就那么几种。我习惯记成四类：
- AUX Read / Write —— 直接读写DPCD寄存器，比如查链路状态
- I²C Read / Write —— 通过AUX隧道读写下游I²C设备，比如DDC总线的EDID
- I²C Read-Modify-Write —— 针对只读寄存器做掩码操作（较少用）
- AUX Native —— 留给厂商自定义扩展，比如SCDC的一些特殊命令
说到HDCP协商，AUX在这个阶段扮演的角色特别重要。HDCP 2.2在DP上的密钥交换几乎全靠AUX传消息。我记得处理过一个Bug：HDCP 1.x握手能过，但2.2就是失败，最后发现是AUX事务层重试次数不够导致的。代码里加了个超时重试逻辑就好了。
1.4 常见用途
AUX通道在日常调试中扮演三个核心角色，我按使用频率排个序：
- DPCD寄存器访问 —— 所有链路训练、链路状态、供电状态都通过DPCD暴露出来。我调DP几乎天天跟DPCD打交道。
- EDID读取 —— 源端通过AUX发出I²C写请求，指定地址为0xA0/0xA1，读回EDID块。我曾遇到因为EDID校验和错误导致HDCP协商失败的情况。
- HDCP密钥交换 —— 无论是1.x的KSV还是2.2的LC、SKE，都靠AUX传递消息。密钥数据量大时，AUX的Mbps速率反而成了瓶颈。
另外，SCDC（Status and Control Data Channel）也在AUX上跑，用于HBR3的FRL配置。你想想看，没有AUX，这些控制面数据传输就会挤占主链路带宽，效率极低。
嗯，这张图帮你理清了AUX通道的物理层、事务层到应用层的关系。实际调试时，我会从最右下的“常见用途”反向推理——如果EDID读不到，先查事务层有没有正常发Request，再查物理层眼图好不好。一层层剥洋葱，问题跑不掉。