首页 解决方案 MIPI CSI 规范与协议介绍

MIPI CSI 规范与协议介绍

September 24,2026

介紹

本文介绍 MIPI CSI-2 相机接口的系统架构、D-PHY 传输、数据包机制、图像格式与带宽估算,以及 Linux media-controller 架构下的集成与故障排查。内容适用于 ARM SoC、图像传感器、ISP 与 V4L2 视频管线的软硬件集成。

图像传感器与处理器之间的 MIPI CSI-2 相机接口

MIPI CSI 系统架构

MIPI CSI-2(Camera Serial Interface 2)是用于将图像数据从图像传感器传输至 SoC、ISP 或 FPGA 的高速串行协议。CSI-2 定义数据包格式、Data Type、Virtual Channel 与错误保护机制,而 D-PHY 或 C-PHY 则负责物理信号传输。

MIPI CSI-2 系统架构中的控制路径与图像数据路径

层级 主要职责 典型 Linux / SoC 实现
控制平面 模式、曝光、增益与流控制 Sensor driver 与 I²C/I³C
CSI-2 协议层 数据包化、VC、DT、ECC 与 CRC CSI-2 TX/RX controller
PHY 层 LP/HS 状态、时钟与差分信号 D-PHY/C-PHY 与 PHY driver
图像管线 解码、处理、DMA 与采集 ISP、DMA 与 V4L2 node
 

D-PHY 传输与时序

D-PHY Data Lane 在空闲时处于 LP Stop State,并通过 LP 状态序列切换至 HS 模式后传输 CSI-2 数据包。Sensor 寄存器访问与流控制通常通过独立的 I²C/I³C 总线进行,与 D-PHY Data Lane 的 LP 状态不同。

D-PHY Data Lane 从 LP Stop State 切换至 HS 传输

状态 / 阶段 作用 集成要点
LP-11 Stop State 空闲状态及 LP 操作的基础状态 确认 lane 状态及 TX/RX PHY 支持情况
LP-01, LP-00 HS 进入/退出序列的一部分 不得将这些状态解读为 I²C 控制数据
HS-Prepare, HS-Zero 高速传输前的准备与稳定阶段 影响 RX 检测与 HS-Settle 调整
SoT 标记高速数据包传输的开始 SoT 错误可能表示时序、lane 或配置存在问题
HS data transmission 传输 CSI-2 packet byte stream 确认 link frequency、lane 数量及信号完整性
 
  • 在 clocked mode 下,Clock Lane 在 HS 传输期间支持接收端采样。continuous 或 non-continuous clock 的工作方式应根据图像传感器、SoC PHY 与 driver 配置进行确认。
  • HS-Settle 应根据实际 link frequency、SoC receiver 文档与错误计数器进行调整;并非数值越大越好。
 

CSI-2 数据包与同步

CSI-2 使用 Short Packet 传递协议事件或同步信息,而 Long Packet 用于传输 RAW、YUV、RGB 或 embedded data。Long Packet 由 4-byte header、payload 和 2-byte CRC footer 组成。

CSI-2 Frame 与图像 Long Packet 的基本顺序

字段 功能 检查要点
Virtual Channel (VC) 区分逻辑数据流 Sensor 与 RX Virtual Channel 必须兼容
Data Type (DT) 表示像素格式或数据包类型 必须与 Sensor output mode 及 RX 支持能力相匹配
Word Count (WC) 表示 Long Packet payload 的字节数 应与 line width 和 pixel packing 相匹配
ECC 保护 packet header 检查同步、lane、配置及 RX 解码
CRC 保护 Long Packet payload 检查 PHY、data rate、lane mapping 及 TX/RX 实现
 

Frame Start(FS)和 Frame End(FE)提供 frame-level synchronization。Line Start(LS)和 Line End(LE)提供可选的 line-level synchronization。LS 和 LE 是否实际输出,应根据 Sensor 文档、CSI receiver trace 或 driver 计数器进行确认。

图像格式与带宽

CSI-2 Data Type、V4L2 media-bus code、V4L2 capture memory format 与 ISP format negotiation 必须在数据含义上保持兼容,但它们属于不同的抽象层,因此配置名称与位置不需要一一对应。对于 RAW 数据,还需确认 bit depth 和 Bayer order;对于 YUV 数据,则需确认 byte order。

Active-pixel payload 的下限可估算如下:

Active-pixel payload = Width × Height × FPS × Bits per pixel

上述计算仅代表有效像素数据所需的最低 payload。实际 CSI-2 throughput 与 D-PHY lane rate 还需考虑 packet header、CRC、同步数据包、blanking 传输策略、Data Lane 数量、clock mode、Sensor 可用的 link-frequency 设置,以及 SoC CSI receiver 的限制。

Per-lane rate ≳ Total CSI-2 throughput / Number of Data Lanes

Linux 集成与 Bring-up

Device Tree 通常用于描述 graph endpoint、data-lanes、clock-lanes 以及 remote-endpoint 连接。在大多数 media-controller 架构中,图像格式会在运行时通过 sub-device pad format、media link 与 routing negotiation 进行协商。实际 binding 与支持的格式取决于目标 SoC 的 kernel driver。

# 查看 entity、pad 与 link
media-ctl -p -d /dev/media0

# 示例:配置上游 Sensor pad format
media-ctl -d /dev/media0 --set-v4l2 '"sensor 1-001a":0 [fmt:SRGGB10_1X10/1920x1080]'

# 示例:启用 link
media-ctl -d /dev/media0 --links '"sensor 1-001a":0 -> "csi2rx":0 [1]'

# 配置 capture node memory format 并开始流传输
v4l2-ctl -d /dev/videoX \
  --set-fmt-video=width=1920,height=1080,pixelformat=RG10 \
  --stream-mmap=4 --stream-count=100

dmesg -w
 

本示例中的 entity 名称、pad index、media-bus code、FourCC 值与 video node 均需根据实际 media graph 进行调整,并非所有平台都使用相同设置。

Linux media-controller 架构下的 CSI-2 Bring-up 与故障排查流程

兼容性与错误分析

类别 检查要点 典型现象
PHY Lane 数量、mapping、link frequency、clock mode 与 HS-Settle SoT 错误、无数据或间歇性丢帧
协议 VC、DT、数据包行为与 ECC/CRC Header 错误、CRC 错误或帧同步异常
格式 Bit depth、Bayer order、YUV order 与 packing 颜色异常、绿屏或图像破损
Pipeline DT graph、media link、pad format、ISP 与 DMA STREAMON 失败或 buffer timeout
 
  • 如果 I²C 通信正常但无法接收到图像,请检查 power/reset/MCLK、Sensor stream-on 状态、data-lanes、lane mapping、link frequency、media graph 与 CSI RX 状态。
  • 如果检测到 frame activity,但出现 ECC/CRC 错误,请检查 RX 错误计数器、lane mapping、link rate、HS-Settle、板级信号完整性以及 TX/RX 配置。
  • 如果能够采集 frame 但颜色异常,请检查 RAW bit depth、Bayer order、media-bus code、memory FourCC 与 ISP pipeline。
 

常见问题

1. CSI-2 和 D-PHY 是一样的吗?

不是。CSI-2 是图像数据包协议,而 D-PHY 是常用的物理层传输接口。

2. 为什么 I²C 通信正常,却没有图像?

I²C 通信正常仅代表控制通道工作正常。图像数据路径仍可能受到 MCLK、lane、PHY 时序、协议、media graph、ISP 或 DMA 等问题的影响。

3. ECC 和 CRC 有什么区别?

ECC 主要用于保护 Packet Header,可纠正单 bit 错误并检测双 bit 错误。CRC 用于验证 Long Packet payload 的完整性。如果错误持续发生,通常需要同时检查协议配置与物理层信号完整性。

4. 为什么同一个图像传感器在不同板卡上的表现会有所不同?

PCB 阻抗、走线长度、FPC、接地回流路径及 EMI 条件都可能影响 D-PHY 的信号完整性与时序裕量。

参考资料

  • MIPI Alliance, "Camera Serial Interface 2 (MIPI CSI-2)", mipi.org/specifications/csi-2
  • MIPI Alliance, "MIPI D-PHY", mipi.org/specifications/d-phy
对显示器解决方案有疑问?您想做的,由我们实现。 联络我们!

订阅

接收最新显示器技术知识与新品消息

联络我们

价格/规格书/一般查询

技术支持

联系我们询问技术内容

go top
联络我们
close

我们重视您的隐私

通过点击「允许所有 Cookie」,代表您同意在您的设备上存储 Cookie 以增强网站浏览体验、分析网站使用情况并协助我们的营销和网站效能优化工作。您可以在我们的隐私权政策中找到有关于此的更多信息。

我们重视您的隐私

Winstar 及部分第三方在 www.winstar.com.tw 上使用 cookies。关于 cookie 的种类、用途及相关第三方的详细信息,请参见下文及我们的《Cookie 政策》。请点击“允许全部”来同意我们使用 cookies,以确保您在我们网站上获得最佳体验。您也可以设置您的偏好或拒绝 cookies(必要的 cookies 除外)。

管理同意声明

永久启用
必要的 Cookie

这些 Cookie 是必不可少的,以便让您在浏览网站并使用其功能上有更好地体验,例如设置您的隐私偏好、登录或填写窗体。

分析 Cookie

这些也被称为「统计cookie」,用于收集您使用网站的信息,例如您访问了哪些页面以及点击了哪些连结。查看详细信息