4、MIPI接口详解：CSI-2协议层、D-PHY物理层、Lane速率计算、多路数据流同步
MIPI接口，说白了就是摄像头和处理器之间的“高速公路”。我做了这么多年Camera驱动，见过太多因为MIPI配置不对导致的黑屏、花屏问题。这一章，咱们就把这条高速路的规矩彻底讲清楚。
4.1 整体架构：三层分工
MIPI CSI-2的架构分三层，每一层各司其职。我习惯用快递系统来打比方，你一听就懂。
- 应用层：打包货物的人。决定数据怎么封装，比如RAW10、YUV422这些格式。
- 协议层：贴快递单的人。负责把数据拆成包，加上包头包尾，告诉接收方“这是哪一帧、哪一行”。
- 物理层：送货的卡车司机。负责在Lane上高速传输0和1，保证信号不丢包。
核心要点：调试MIPI问题时，先确认物理层通不通，再看协议层对不对。我见过有人花三天查协议，结果发现是D-PHY电压配错了。
4.2 D-PHY物理层：信号怎么跑
D-PHY是MIPI的物理层标准。说白了，就是一对差分线（Dp/Dn）在跑数据。我刚开始调驱动时，总觉得差分信号很玄乎，其实你把它想象成两个人抬轿子——一个抬正相，一个抬反相，步调一致才能走得稳。
4.2.1 两种模式：HS和LP
| 模式 | 电压摆幅 | 速率 | 用途 |
|---|---|---|---|
| HS (High Speed) | 200mV 差分 | 80 Mbps ~ 4.5 Gbps | 传输像素数据 |
| LP (Low Power) | 1.2V 单端 | ~10 Mbps | 控制信号、总线周转 |
嗯，这里要注意：HS模式才是真正干活的时候，LP模式只是用来打招呼的。我曾经遇到一个案子，Sensor输出的LP信号时序不对，导致SoC一直识别不到数据开始，画面全黑。查了两天才发现是LP-11状态保持时间不够。
4.2.2 Lane结构
一个MIPI接口至少有一条时钟Lane和一条数据Lane。时钟Lane负责提供同步时钟，数据Lane负责传数据。数据Lane可以扩展，1条、2条、4条都很常见。
个人经验：4条Lane的配置最常用。但如果你板子走线空间紧张，2条Lane也能跑1080P@30fps，只要把速率翻倍就行。不过速率高了信号容易出问题，这是个取舍。
4.3 CSI-2协议层：数据怎么打包
协议层负责把像素数据打包成“数据包”。每个包都有固定的格式，就像快递包裹必须有面单一样。
4.3.1 包结构
- 短包 (Short Packet)：只有32位数据，用于帧同步、行同步。比如帧开始(FS)、帧结束(FE)、行开始(LS)。
- 长包 (Long Packet)：包含真正的像素数据。结构是：包头(32位) + 数据负载 + 包尾(16位CRC校验)。
// 长包结构示意
// [Data ID (8bit)] [Word Count (16bit)] [ECC (8bit)] [Payload] [CRC (16bit)]
// 举例：RAW10格式，一行1920像素
// Data ID = 0x2A (虚拟通道0，数据类型RAW10)
// Word Count = 1920 * 10 / 8 = 2400 字节
// ECC = 对前32位做纠错码
// Payload = 2400字节像素数据
// CRC = 对Payload做循环冗余校验避坑指南：我曾经遇到一个Bug，画面出现随机条纹。查到最后发现是Word Count算错了——RAW10每像素10bit，不是2字节！Word Count的单位是字节，一定要按位宽换算清楚。
4.3.2 数据类型 (Data Type)
协议层用Data ID字段告诉接收方“我传的是什么格式”。常见的DT值如下：
| 数据类型 | DT值 (Hex) | 说明 |
|---|---|---|
| RAW6 | 0x28 | 6位原始数据 |
| RAW8 | 0x2A | 8位原始数据，最常用 |
| RAW10 | 0x2B | 10位原始数据 |
| RAW12 | 0x2C | 12位原始数据 |
| YUV422 8bit | 0x1E | YUV格式 |
| JPEG | 0x40 | 压缩图像数据 |
4.4 Lane速率计算：到底能跑多快
这是调驱动时最常算的公式。说白了，就是算一算你的MIPI总线能不能撑住Sensor输出的数据量。
4.4.1 计算公式
单Lane速率 (Mbps) = (帧率 × 分辨率宽 × 分辨率高 × 每像素位数) / (Lane数 × 1000000)
举例：1920x1080 @ 30fps, RAW10, 4 Lane
= (30 × 1920 × 1080 × 10) / (4 × 1000000)
= 622080000 / 4000000
= 155.52 Mbps嗯，算出来是155.52 Mbps。但实际配置时，我建议留20%~30%的余量。为什么？因为还有消隐区（Blank）的开销。Sensor输出一行数据，中间有H-Blank，帧之间有V-Blank，这些时间也要算进去。
实际经验：我一般按公式算完后，再乘以1.3。比如上面算出来155.52 Mbps，实际配置到200 Mbps左右比较稳妥。如果配得太紧，帧率可能跑不满，或者出现丢帧。
4.4.2 常见分辨率速率参考
| 分辨率 | 帧率 | 格式 | Lane数 | 单Lane速率 |
|---|---|---|---|---|
| 640x480 | 60 | YUV422 | 1 | ~74 Mbps |
| 1920x1080 | 30 | RAW10 | 4 | ~156 Mbps |
| 3840x2160 | 30 | RAW10 | 4 | ~622 Mbps |
| 3840x2160 | 60 | RAW10 | 4 | ~1244 Mbps |
注意：D-PHY v1.2的单Lane理论上限是4.5 Gbps，但实际板子上超过1.5 Gbps就容易出信号完整性问题。4K@60fps用4 Lane跑1.2 Gbps，对PCB走线要求很高。我建议这种场景考虑C-PHY或者用8 Lane。
4.5 多路数据流同步：多个摄像头怎么协调
现在的手机动辄三摄、四摄，多路数据流同步是个大难题。CSI-2协议层提供了两种机制来解决这个问题。
4.5.1 虚拟通道 (Virtual Channel)
虚拟通道是CSI-2协议层的一个字段，占2位，所以最多支持4个虚拟通道（VC0~VC3）。多个Sensor可以共享同一条MIPI总线，通过VC来区分数据属于哪个Sensor。
// 虚拟通道在Data ID中的位置
// Data ID [7:6] = Virtual Channel
// Data ID [5:0] = Data Type
// 例如：0x6A = VC1 + RAW8
// 0x2A = VC0 + RAW8我做过一个双摄项目，主摄用VC0，副摄用VC1，共用4条Lane。主摄跑30fps，副摄跑15fps，通过VC区分。但要注意，两个Sensor的帧率必须同步，否则会出现数据交错。
4.5.2 帧同步 (Frame Sync)
多路数据流同步的核心是帧同步。说白了，就是让所有Sensor在同一时刻开始曝光、同一时刻输出数据。硬件上通常用一根SYNC信号线连接所有Sensor，软件上通过I2C配置同步模式。
我的做法：一般先让主摄输出FS（帧开始）信号，副摄检测到这个信号后开始曝光。这样能保证所有Sensor的帧边界对齐。如果不对齐，双摄融合算法会算出错误的深度图。
4.5.3 同步时序要求
| 参数 | 要求 | 说明 |
|---|---|---|
| 帧开始偏差 | < 1行时间 | 所有Sensor的FS信号偏差不能超过一行 |
| 曝光时间一致 | ±1% | 曝光时间差异会导致亮度不一致 |
| MIPI时钟同源 | 必须 | 所有Sensor使用同一时钟源 |
避坑指南：我曾经遇到一个案子，双摄画面总是差几行。查到最后发现是Sensor的PLL配置不同，导致内部时钟有微小偏差。解决办法是让两个Sensor用同一个MCLK，并且PLL配置完全一致。
4.6 本章小结
MIPI接口是Camera系统的命脉。物理层决定了信号能不能传过去，协议层决定了数据怎么解析，速率计算决定了能不能跑满帧率，多路同步决定了多摄能不能协同工作。调MIPI时，我建议按这个顺序排查：先看D-PHY的LP状态机是否正常，再看HS模式能否锁定，然后检查协议层的包结构，最后确认速率是否在预算范围内。