手机mipi数据传输

 如下转自http://blog.163.com/zz_forward/blog/static/2128982222012869180987

随着客户要求手机摄像头像素越来越高，同时要求高的传输速度，传统的并口传输越来越受到挑战。提高并口传输的输出时钟是一个办法，但会导致系统的EMC设计变得越来困难；增加传输线的位数是，但是这又不符合小型化的趋势。采用MIPI接口的模组，相较于并口具有速度快，传输数据量大，功耗低，抗干扰好的优点，越来越受到客户的青睐，并在迅速增长。例如一款同时具备MIPI和并口传输的8M的模组，8位并口传输时，需要至少11根的传输线，高达96M的输出时钟，才能达到12FPS的全像素输出；而采用MIPI接口仅需要2个通道6根传输线就可以达到在全像素下12FPS的帧率，且消耗电流会比并口传输低大概20MA。由于MIPI是采用差分信号传输的，所以在设计上需要按照差分设计的一般规则进行严格的设计，关键是需要实现差分阻抗的匹配，MIPI协议规定传输线差分阻抗值为80-125欧姆。

 

 

上图是个典型的理想差分设计状态，为了保证差分阻抗，线宽和线距应该根据软件仿真进行仔细选择；为了发挥差分线的优势，差分线对内部应该紧密耦合，走线的形状需要对称，甚至过孔的位置都需要对称摆放；差分线需要等长，以免传输延迟造成误码；另外需要注意一点，为了实现紧密的耦合，差分对中间不要走地线，PIN的定义上也最好避免把接地焊盘放置在差分对之间（指的是物理上2个相邻的差分线）。

下面简单介绍MIPI的通道模式和线上电平。在正常的操作模式下，数据通道处于高速模式或者控制模式。在高速模式下，通道状态是差分的0或者1，也就是线对内P比N高时，定义为1，P比N低时，定义为0，此时典型的线上电压为差分200MV，请注意图像信号仅在高速模式下传输；在控制模式下，高电平典型幅值为1.2V，此时P和N上的信号不是差分信号而是相互独立的，当P为1.2V，N也为1.2V时，MIPI协议定义状态为LP11，同理，当P为1.2V，N为0V时，定义状态为LP10，依此类推，控制模式下可以组成LP11，LP10，LP01，LP00四个不同的状态;MIPI协议规定控制模式4个不同状态组成的不同时序代表着将要进入或者退出高速模式等；比如LP11-LP01-LP00序列后，进入高速模式。下图为线上电平的图示

 

zane:MIPI接口是一种串口，MIPI相比较DVP接口的优势在于 速度快更有2,4 lane 可选。

如下也是转过来的,方便查看 ,转自http://blog.csdn.net/g_salamander/article/details/9163455

以下是最近几个月在调试 MIPI DSI / CSI 的一些经验总结，因为协议有专门的文档，所以这里就记录一些常用知识点：

一、D-PHY

1、传输模式

LP（Low-Power） 模式：用于传输控制信号，最高速率 10 MHz

HS（High-Speed）模式：用于高速传输数据，速率范围 [80 Mbps， 1Gbps] per Lane

传输的最小单元为 1 个字节，采用小端的方式及 LSB first，MSB last。

2、Lane States

*  LP mode 有 4 种状态： LP00、LP01（0）、LP10（1）、LP11 （Dp、Dn）

* HS mode 有 2 种状态： HS-0、HS-1

HS 发送器发送的数据 LP 接收器看到的都是 LP00，

3、Lane Levels

* LP： 0 ~ 1.2V

* HS： 100 ~ 300mV，HS common level = 200mV，swing = 200 mv

4、操作模式

在数据线上有 3 种可能的操作模式：Escape mode, High-Speed (Burst) mode and Control mode，下面是从停止状态进入相应模式需要的时序：

* Escape mode 进入时序：LP11→LP10→LP00→LP01→LP00，退出时序：LP10→LP11

当进入 Escape mode 需要发送 8-bit entry command 表明请求的动作，比如要进行低速数据传输则需要发送 cmd： 0x87，进入超低功耗模式则发送 cmd： 0x78。在 DSI 中 LP 通讯只用 Data Lane 0。

* High-Speed mode 进入时序：LP11→LP01→LP00→SoT(0001_1101)，退出时序：EoT→LP11，时序图如下：

* Turnaround 进入时序：LP11→LP10→LP00→LP10→LP00，退出时序：LP00→LP10→LP11

这是开启 BTA 的时序，一般用于从 slave 返回数据如 ACK： 0x84。

5、时序要求

在调试 DSI 或者 CSI 的时候， HS mode 下的几个时序非常重要：T_LPX，T_HS-SETTLE ≈ T_HS-PREPARE + T_HS-ZERO，T_HS-TRAIL，一般遵循的原则为：Host 端的 T_HS-SETTLE > Slave 端的 T_HS-SETTLE。

二、DSI

1、线路构成

在 DSI 中需要 1 根时钟线以及 1 ~ 4 根数据线。

2、两种接口的 LCD

* Command mode（对应 MPU 接口）

* Video mode（对应 RGB 接口）

该模式下视频数据只能通过 HS mode 传输。

3、数据包类型

 短包：4 bytes，由 3 部分组成：

* Data Identifier (DI) * 1byte： Contains the Virtual Channel[7:6] and Data Type[5:0].

* Packet Data * 2byte：Length is fixed at two bytes

* Error Correction Code (ECC) * 1byte：allows single-bit errors to be corrected and 2-bit errors to be detected.

长包：6 ~ 65541 bytes，同样由 3 部分组成：

* Packet Header(4 bytes) - 包头

Data Identifier (DI) * 1byte：Contains the Virtual Channel[7:6] and Data Type[5:0].
Word Count (WC) * 2byte：defines the number of bytes in the Data Payload.
Error Correction Code (ECC) * 1byte：allows single-bit errors to be corrected and 2-bit errors to be detected.

* Data Payload(0~65535 bytes) - 有效数据
Length = WC × bytes

* Packet Footer(2 bytes)：Checksum - 包尾
If the payload has length 0, then the Checksum calculation results in FFFFh
If the Checksum isn’t calculated, the Checksum value is 0000h

4、从控制器到外设发送的包类型

    

如果希望从外设读取数据或者状态，则在处理器发送完读取命令后还需要发送 BTA 命令，非读取命令在外设接收成功后会返回 trigger message 0x84。

5、从外设到处理器数据包类型

    

返回的数据一般分为 4 个类型：

* Tearing Effect (TE)：trigger message (BAh)
* Acknowledge：trigger message (84h)
* Acknowledge and Error Report：short packet (Data Type is 02h)
* Response to Read Request：short packet or long packet
Generic Read Response、DCS Read Response（1byte, 2byte, multi byte）

读取数据返回值解析示例如下：

[cpp]  view plain copy

1. - Acknowledge and Error report (if error occurs)   
2. Byte 0 is 0x87 (escape mode low power data transmission header)   
3. Byte 1 is 0x02 (Data type, 8.10 of “MIPI Alliance Specification for DSI”)   
4. Byte 3,2 are error report bits[15:0] (8.9.5 of “MIPI Alliance Specification for DSI”)   
5. Byte 4 is the ECC, calculated from byte 1,2,3   
6.    
7. - Generic Short READ response   
8. Byte 0 is 0x87 (escape mode low power data transmission header)   
9. Byte 1 is 0x11 or 0x12 (8.10 of “MIPI Alliance Specification for DSI”)   
10. Byte 2,3 are the read data. If only 1 byte is returned, byte 3 will be 0x00   
11. Byte 4 is the ECC, calculated from byte 1,2,3   
12.    
13. - Long READ packet response   
14. Byte 0 is 0x87 (escape mode low power data transmission header)   
15. Byte 1 is 0x1A (8.10 of “MIPI Alliance Specification for DSI”)   
16. Byte 3,2 are the word count N (N=0 to 65535)   
17. Byte 4 is the ECC, calculated from byte 1,2,3   
18. Byte 5 to byte 5+N-1 are the N-byte read data   
19. Byte 5+N+1, byte 5+N are the checksum, calculated on byte 5 to byte 5+N-1. If   
20. checksum is not calculated by peripheral, this field is 0x0000.   

6、Video 模式的 3 种数据格式

    

* Non-Burst Mode with Sync Pulses
* Non-Burst Mode with Sync Events
* Burst Mode

* 调试记录

        LCD半边闪屏问题，原厂给的信息：分析了系統板送出的 video mode timing，資訊摘要如下

        HSCLK: 160MHz 
        Per lane bit-rate: 320Mbps (UI=3.125ns) 
        HS SoT HS-prepare + HS-zero 約 155ns   

        由上述的 timing 懷疑與現象是因為 IC HS data settle timing 搭配不當所導致
        看来是我们输出的mipi信号 HS-prepare + HS-zero 比 LCD 默认设置短引起的。还有随机整屏闪动的问题通过调节 VFP 和 VBP 的值调到了理想状态。另外 LCD 的 VCC 在使用 mos 管控制后休眠后会有 2.0V 的悬浮电压，通过 RC 电路将电压放掉，将 C78 换成了 10K 电阻。
        LCD电路上有几个比较重要的电压: AVDD、VCC、VGH、VGL、HAVDD、VCOM（由AVDD通过电阻分压得到）

* 唤醒慢的问题

在最初调试的几款 LCD 里面初始化 cmd 都比较少，后来在调试一款 IPS 屏的时候发现唤醒需要 3 秒左右，这款 LCD 初始化 cmd 有100多条，之前在调试一款 LCD 的时候每条 cmd 发送之后需要 delay 10ms 再发下一条 cmd，所以在这款 LCD 这里不能有 delay，并且经过调试在确保发送成功的情况下将 LP 的传输速度提高了 3 倍（这里需要读取每条 cmd 的返回值 0x84 确认命令是否发送成功），优化后唤醒时间不到 1 秒。

* LCD 参数理解更正

才发现之前一直对 LCD 的几个参数 HFP、HBP、VFP、VBP 理解有错误，正确的应该是以同步信号（HSYNC、VSYNC）为基准，在同步信号之前的称为 Front，在同步信号之后的称为 Back，而不是之前理解的以有效像素为基准。

* LCD 显示呈锯齿状问题

这两天（12.11）还调试了一款 540 x 960 分辨率的 mipi LCD，在开始的时候一直点不亮，和供应商确认了好久无意间才发现是他们给的初始化代码是错的，使用正确的初始化代码就能点亮了，不过显示出来的图像却是呈锯齿状的，即没有对齐。之前在别的平台也遇到过类似问题，也就是分辨率不是 16 的整数倍，LCD controller 在取数据的时候会对不齐。边研究 Datasheet 边和 ASIC 同事讨论，后来确定了一个方案：即在 DSI、LCD 寄存器里面设置分辨率为 540 x 960 以让 LCD 正确识别信号，但 framebuffer 需要设置为 544 x 960 以对齐，并且设置 Source pitch 寄存器为 544，这样显示就正常了，相当于 framebuffer 里每一行的最后 4 个 pixel 会被 LCD controller 丢掉。

今天（12.12）在和 ASIC 同事的讨论下更正了之前的理解：LCD controller 在计算取数据的时候，地址是根据（x，y）坐标来算的，差不多是address = y * pitch + x + base，pitch 就是一行 pixel 在内存里的大小，这个至少是要对齐到 8byte， 因为 bus 宽度是 8byte，如 Data sheet 中的描述 ”Source pitch for RGB channel, QWORD aligned if linear mode“。之前计算 pitch 值的公式为：xres / 8 * bits_per_pixel / 8，如果 xres = 540，bits_per_pixel = 32，计算的结果因为取整的原因为 0x10c，实际上正确的值应该是 0x10e，所以需要将公式改为：xres * (bits_per_pixel / 8) / 8，即在每个像素占 4byte 的情况下只要 xres 为偶数就可以满足对齐的要求，而不用改为 544。