DP与HDMI、MIPI各种协议介绍、行/场消影&时钟计算

关注

原创 2024-03-31 18:59:39 1.9w 阅读 AI 写同款· GEO 优化 ›

GSV1127芯片HDMI/DP转MIPI CSI配置保姆级教程视频接口转换是嵌入式视觉中的常见需求，HDMI和DisplayPort作为标准输入源，而MIPI CSI则是应用处理器通用的摄像头接口。通过桥接芯片实现接口互转，可解决多款SoC缺少HDMI输入的问题。本文以GSCoolink GSV1127为例，解析HDMI/DP转MIPI CSI的实现原理与硬件设计要点，涵盖EDID配置、I2C通信、MIPI时序参数计算、V4L2驱动适配等关键环节，并分享实际调试中花屏、黑屏等问题的排查经验。适用于视频采集盒子、内窥镜、工业相机等场景的开发者。阅读详情

1. DP(display port)和HDMI

1. DP(display port)和HDMI

这两种都是高速高质量多媒体传输协议。同时包括音视频的传输。

2. MIPI的各种协议

MIPI(mobile industry processor interface)是为移动产业制定的一系列处理接口。

在这里主要介绍视频图像相关的 CSI和DSI协议。

CSI：camera serial interface。相机端的高速串行接口

DSI：display serial interface 。显示端的高速串行接口

Understanding MIPI Interface - 知乎1. 简介移动产业需要一个标准的，强大的，可扩展的，低功耗，且支持移动设备的多种成像解决方案的摄像机接口。在摄像机领域，传感器与单片机之间的接口标准有很多，如UART、I2C、I2S、SPI、SDIO等串行接口，同时也…https://zhuanlan.zhihu.com/p/100476927

详解MIPI协议详解MIPI协议http://www.360doc.com/content/21/0802/09/38894361_989167945.shtml

3. 行场消影

在camera和display这两端都会有消隐的概念在里面。

在图像和视频的采集端camera，由于扫描像素是从左到右，从上到下，在像素行尾和帧尾分别需要换行从头开始和换帧从右下到左上的过程。就分别对应了行消隐和场消隐。

数字液晶显示消隐区，行消隐，场消隐，消隐前肩，消隐后肩等基本概念https://blog.csdn.net/yh13572438258/article/details/121383553?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2~default~CTRLIST~Rate-1.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2~default~CTRLIST~Rate-1.pc_relevant_default&utm_relevant_index=1 数字图像信号水平消隐，垂直消隐，前肩，后肩等基本概念_re_call的博客-CSDN博客_前肩后肩在做数字图像处理时，必然要接触比如水平消隐，垂直消隐，前肩，后肩等基本概念，下面图示了水平前肩，水平后肩，垂直前肩和垂直后肩。数字视频的基本概念源自于模拟视频，因为先有模拟显示器后有数字显示器的。对于模拟视频我们可以这样理解：视频可以分解为帧，每帧分为为若干个基本视点（像素），每个像素都有独立的色彩信息，在屏幕上依次将这些点用电子枪按照行和列打出来，就形成了一幅完整画面，连续的打出画面，利用人...https://blog.csdn.net/re_call/article/details/105756273

4. DP/HDMI/MIPI的区别

这些都是音视频传输协议，提出这些协议的机构不同，它们各自的应用场景也不同，因为场景的不同会导致各自支持的格式，带宽，传输距离的差别。

DP是一个由PC及芯片制造商联盟开发，视频电子标准协会（VESA）标准化的数字式视频接口标准。传输距离在10m。可以传输音视频。只支持progressive，不支持interlaced

HDMI是开始是由日立、松下、飞利浦、SiliconImage、索尼、汤姆逊、东芝等7家公司于2002年共同组建了HDMIHD多媒体接口组织，现在已经是独立的HDMI组织。标称传输距离也在10m。可以传输音视频。同时支持progressive和interlaced(1080I等)。

MIPI的DSI，CSI是移动产业处理器联盟给出的标准，早期是用于手机内部摄像头，显示器与soc的连接。既然是手机内部的信号传输，在早期肯定就没考虑过过长的传输距离。一般传输距离在2，3m。DSI/CSI都不支持音频。只支持progressive，不支持interlaced。

4.1 controller的区别

dsi controller与phy之间是ppi接口，ppi_clk和pixclk没有必然的关系，能保证ppi接口总的dataRate>pixRate就行。这一点和hdmi不同，hdmi controller 的linkqpclk与pixclk和pixWidth是固定关系，保证hdmi controller输入和输出的速率是一致的。所以dsi controller内要有lineBuff 而hdmi controller里面没有行级存储。

mipi dsi/csi+dphy都没有使用添加冗余bit的编码(8/10b,128/130b 编码），DC均衡只用scramble。

HDMI使用TMDS编码，DP/eDP使用 8/10b编码

csi/dsi都是按照pixData实际有效bit来处理像素。hdmi不是这样，hdmi的YUV422 无论8/10/12bit经过controller都按照12bit来处理，这一点下文会详细介绍。

4.2 phy的区别

dphy的差分clk_n/p和 data lane的dataRate可以大于实际分辨率x帧率传输所需要的时钟。这就需要sink端能够有缓存，保证dphy以大于实际需求的图像传输clk传输图像视频时，sink端能正常显示。因dsi controller最多是一行图像组一个包，所以sink端最多要有一行lineBuff就够.

dsi+dphy传输时，clk_n/p的时钟是bitrate的1/2.因为可以用clk_n/p的双沿采样数据。

hdmi的phy输出clk就是tmds clk，输出数据就是tmds_data.所以hdmi phy的差分IO命名就是

HDMI_TMDS_CLKN/P

HDMI_TMDSDATAN0~HDMI_TMDSDATAN2

HDMI_TMDSDATAP0~HDMI_TMDSDATAP2

TMDS包含两个概念：

将每8bit原始数据编码为10bit数据----每个编码后10bit称为一个TMDS编码字符

是3个8bit并行编码 Tri-Byte一起TMDS编码

将TMDS字符以差分方式传送

所以TMDS_CLK频率是TMDS数据流的字符速率。也就是每一路tmds_data bitRate的1/10.所以hdmi sink端需要对TMDS_CLK 进行10倍频，在调相之后用来做同步采样时钟。

4.3 hdmi的时钟关系

本节给出TMDS_CLK与linkqpclk，pixclk，vidqpclk，dataLane的bitRate【这里面是3路dataLane上的每一路bitRate】的频率关系

【一个pix是包含该像素的所有颜色分量】

TMDS_CLK：为TMDS编码前 8bit字符的buad rate或者说编码后10bit字符的 buad rate。所以：

$TMDS\_CLK=bitRate/10=triByteClk$

linkqpclk(link quad-pixel clock)：是hdmi controller与hdmi phy的接口频率,从名字可以看出是4pix频率。实际固定为TMDS_CLK的4分频。

$linkqpclk=TMDS\_CLK/4$

pixclk：hdmi controller输入的视频clk。由视频格式(只有YUV420是1T2P，其他都是1T1P)，帧率，等效分辨率(实际图像分辨率+水平消隐+垂直消隐) 决定。CEA(CTA)-861文档给出常见pixclk。

vidqpclk(video datapath clock)：hdmi controller 内部处理clock，以pix为处理单位。考虑到controller中有对pixclk repeat的操作(没有行buff，只能水平repeat)和并行处理的需求。设每个pix repeat的次数为pr_factor 则：

1.当HDMI controller 4路并行处理时

$vidqpclk=(pr\_factor+1)\times pixclk/4$

2.当hdmi controller 单路处理时

$vidqpclk=(pr\_factor+1)\times pixclk$

那么如何建立TMDS_CLK与pixclk的关系呢？

设像素位宽为pixWidth,

则对于RGB或YUV420或YUV444：

$TMDS\_CLK=(pr\_factor+1)\times pixclk\times pixWidth\times 3 /8/3$

'x3'是三个颜色分量。‘/8’是8bit作为一个编码字符。'/3' 是因为有3lane并行处理(3路tmds编码同时处理)。

YUV420可以使用上面的公式计算原因在于YUV420的pixclk是相同分辨率RGB的一半，但是YUV422是有特殊的处理，YUV422数据量是相同分辨率RGB的2/3，pixclk确和RGB同分辨率相同，那么到TMDS接口 YUV422的字符速率应该也是RGB的2/3才对？？？然而实际情况并非如此。

根据对对hdmi qp(quad-pixel 四像素并行) tx controller的学习，发现在YUV422 无论是8/10/12bit在转tri-byte时都是按照24bit处理【不支持16bit yuv422】。如下图：4像素并行且是不区分位宽的。

                                C[11:4]                 Y[11:4]                 C[3:0]              Y[3:0]
obusa_data[47:0] = {8'd0, iipi_data_0[15:8], 8'd0, iipi_data_0[47:40], 8'd0, iipi_data_0[7:4], iipi_data_0[39:36]}
obusb_data[47:0] = {8'd0, iipi_data_1[15:8], 8'd0, iipi_data_1[47:40], 8'd0, iipi_data_1[7:4], iipi_data_1[39:36]}
obusc_data[47:0] = {8'd0, iipi_data_2[15:8], 8'd0, iipi_data_2[47:40], 8'd0, iipi_data_2[7:4], iipi_data_2[39:36]}
obusd_data[47:0] = {8'd0, iipi_data_3[15:8], 8'd0, iipi_data_3[47:40], 8'd0, iipi_data_3[7:4], iipi_data_3[39:36]}

所以对于下面的公式的特例情况就是当YUV422时，无论实际pixWid为8/10/12,计算的时候pixWidht=8

$TMDS\_CLK=(pr\_factor+1)\times pixclk\times pixWidth\times 3 /8/3 \\(when \quad YUV222 \quad pixWidth === 8)$