基於Linux核心的OMAP3530 LCD屏驅動調試小記

背景：

　　　公司要在
OMAP3530平台上做產品，現在處於技術調查階段。需求點之一是修改現有的3寸LCD屏為7寸屏。

問題：

　　　我們使用
的是瑞泰提供的開發板，開發文檔中有關於屏使用的介紹。按照文檔中提供的核心編譯選項，找到對應的LCD屏驅動檔案後，進行參數設定，沒有效果，（最明顯
的一個參數是時鐘頻率，修改後，應當花屏，事實上是還正常顯示）。

解決過程：

1、把參數都改亂測試，沒有效果，懷疑修改錯文
件。

2、取消模組向DSS系統的註冊動作，螢幕變黑，說明所修改檔案還是起作用的。

3、找瑞泰支援人員詢問，沒有得到有用的
答案，放棄使用詢問支援人員的權利。

4、OMAP相關技術群裡尋找有這方面經驗的人，提供參考意見，有經驗的人都說改那檔案的參數就起作用
的，見鬼了。

5、聯機調核心，跟蹤代碼試試。結果聯機調很麻煩，配了半天環境沒配成，放棄此方案。

6、使用最古老的打LOG
方式，在相關地方都打上調試資訊的輸出，配合SourceInsigh查看代碼的調用流程，最終找到了問題所在。

問題原因：

　
　核心啟動時，給omapfb模組傳入了顯示設定的參數470×272MR-16@60，顯示子系統(DSS)解析此參數，並對所顯示結構體中的
panel->timings成品進行賦值，而此成員的值便是瑞泰文檔中所提到的驅動檔案中設定的，因此無論在該檔案如何修改參數，系統都能正常顯
示。

修改方案：

　　修改解析參數並給display->panel->timings賦值的地方，取消賦值操
作。

方案驗證：

　　修注釋掉該調用後，系統直接崩潰。

新問題調查：

　　定位出問題的程式碼後，
發現我們的參數在設定時，超出了合法範圍，改小該值，並使用示波器測試時鐘頻率和相應訊號與在驅動檔案中設定的值相同。問題最終解決，總共使用時間七個工
作日。