原文地址：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

* 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

* Comman 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   
6. - Generic Short READ response   
7. Byte 0 is 0x87 (escape mode low power data transmission header)   
8. Byte 1 is 0x11 or 0x12 (8.10 of “MIPI Alliance Specification for DSI”)   
9. Byte 2,3 are the read data. If only 1 byte is returned, byte 3 will be 0x00   
10. Byte 4 is the ECC, calculated from byte 1,2,3   
11. - Long READ packet response   
12. Byte 0 is 0x87 (escape mode low power data transmission header)   
13. Byte 1 is 0x1A (8.10 of “MIPI Alliance Specification for DSI”)   
14. Byte 3,2 are the word count N (N=0 to 65535)   
15. Byte 4 is the ECC, calculated from byte 1,2,3   
16. Byte 5 to byte 5+N-1 are the N-byte read data   
17. Byte 5+N+1, byte 5+N are the checksum, calculated on byte 5 to byte 5+N-1. If   
18. checksum is not calculated by peripheral, this field is 0x0000.   

* 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。