mipi 的LCD調試經驗

以下是最近幾個月在調試 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

- Acknowledge and Error report (if error occurs)
Byte 0 is 0x87 (escape mode low power data transmission header)
Byte 1 is 0x02 (Data type, 8.10 of “MIPI Alliance Specification for DSI”)
Byte 3,2 are error report bits[15:0] (8.9.5 of “MIPI Alliance Specification for DSI”)
Byte 4 is the ECC, calculated from byte 1,2,3
- Generic Short READ response
Byte 0 is 0x87 (escape mode low power data transmission header)
Byte 1 is 0x11 or 0x12 (8.10 of “MIPI Alliance Specification for DSI”)
Byte 2,3 are the read data. If only 1 byte is returned, byte 3 will be 0x00
Byte 4 is the ECC, calculated from byte 1,2,3
- Long READ packet response
Byte 0 is 0x87 (escape mode low power data transmission header)
Byte 1 is 0x1A (8.10 of “MIPI Alliance Specification for DSI”)
Byte 3,2 are the word count N (N=0 to 65535)
Byte 4 is the ECC, calculated from byte 1,2,3
Byte 5 to byte 5+N-1 are the N-byte read data
Byte 5+N+1, byte 5+N are the checksum, calculated on byte 5 to byte 5+N-1. If
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。

http://blog.csdn.net/g_salamander/article/details/9163455