轉載于：https://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）

讀取數據返回值解析示例如下：

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

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

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。

??

總結

以上是生活随笔為你收集整理的mipi 协议简介[通俗易懂]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。