相容方案

定做LCD fpc

該方案是硬體設計時預留幾個gpio，不同廠家的屏對不同的gpio進行上拉或者下拉，將上下拉電阻直接貼到fpc上，
系統啟動時讀取gpio電平進行判斷。
優點：
    硬體更改版號時不需要考慮屏的區別，軟體無需單獨出版本，生產時也沒有燒錄錯誤的風險，該方案對我們來說是最簡單的。
缺點：
    需要模組廠配合。

軟體讀取IC的 ID

該方案是在系統啟動時讀取 LCD IC的暫存器，不同的IC其內容不同，以此達到區分的目的。
優點：
    該方案不需要模組廠配合，硬體也無需考慮屏的區別，在明確LCD IC的情況下，可以考慮使用。
缺點：
    如果不同模組廠使用的是相同的IC該方案便不可行。

 

使用gpio

該方案對軟體來說與方案1相同，不同點在於該方案是將上下拉電阻貼到PCB板上。
優點：
    不依賴模組廠。
缺點：
    針對不同的屏在貼片時需要做區分，如果後期改換其他屏，需要修改電阻，該方案只能做到軟體相容，硬體無法相容。

增加特定分割槽

該方案是在原有的emmc或ufs分割槽的基礎上增加一個oem分割槽，在生產時針對不同的屏燒錄對應的oem.img檔案即可。
優點：
該方案可以做到軟硬體同時相容，如果後期需要更換，只需要重新燒錄對應的oem.img檔案即可，同時一些特有的資訊也可以新增到該分割槽，
軟體升級時無需對該分割槽進行操作。
缺點：
生產時需要區分不同的屏，不能出現燒錄錯誤的情況，否則會出現顯示異常。
 

Parameter.txt（rk平臺特有）

該方案效果與方案4相同，都是修改commandline，區別在於方案4是讀取oem分割槽的內容後再修改，該方案時直接修改原始commandline。
優缺點與方案4相同。

根據專案實際情況採用方案5， 以下介紹相容過程中涉及的修改。

Android5.1

Device tree修改

公共部分

由於該平臺在LCD相容方面做的不完善，無法直接將不同dtsi檔案包含到平臺中，所有LCD devicetree檔案中包含的內容是完整的（LCD的上下電、reset、command、timging等），因此需要將不同的devicetree之間相同的部分抽離出來。中對應的是下圖部分（lcd-power-common-gpio.dtsi），該部分是對LCD的上下電和reset操作。

不同部分

不同的LCD其command和timing會有所區別，需要將這部分獨立出來, 如下圖:

由於程式碼在解析dtb檔案時是通過名稱來匹配，因此在抽離不同部分後需要修改對應的節點名稱：

uboot 程式碼修改

在進行LCD初始化前，讀取parameter.txt中commandline的LCD資訊，儲存在global date結構中。使用方案5時commandline中已經包含了LCD資訊，因此uboot中無需修改。

由於在devicetree中修改了dts節點名稱，此處需要根據不同的屏載入對應的內容。

整體的修改思路是：在進行LCD初始化前完成識別操作，原有程式碼初始化LCD時讀取的節點是寫死的，修改後根據判斷動態獲取。

kernel 修改

LCD驅動

Kernel中對LCD驅動的修改思路與修改內容與uboot一樣，此處不在詳細描述，以下是kernel修改的相關patch

請點選繼續閱讀，全文在我的個人部落格，感謝支援。

歡迎訪問我的個人部落格https://intgyl.com/。