做過(guò)幾年底層顯示驅(qū)動(dòng)的開(kāi)發(fā)調(diào)試我一直覺(jué)得這個(gè)方向有個(gè)特別實(shí)在的規(guī)律屏幕亮了不算本事屏幕不亮能定位到具體環(huán)節(jié)才算入門(mén)。顯示驅(qū)動(dòng)調(diào)試工具說(shuō)到底就是幫你在茫茫多的寄存器、時(shí)序參數(shù)、幀緩沖地址、中斷狀態(tài)里快速圈出問(wèn)題所在的那條“追蹤鏈”。前面幾篇聊了DRM框架、fbdev、panel驅(qū)動(dòng)這些基礎(chǔ)知識(shí)這篇就專(zhuān)門(mén)把調(diào)試工具攤開(kāi)來(lái)講清楚——不是羅列工具名單而是告訴你每個(gè)工具在哪個(gè)環(huán)節(jié)用、怎么讀數(shù)、怎么判斷。這篇內(nèi)容適合正在搞Linux DRM/KMS驅(qū)動(dòng)、Android顯示HAL或者在做MIPI DSI、eDP、RGB屏調(diào)試的朋友參考。不管你是剛接觸顯示驅(qū)動(dòng)的初學(xué)者還是已經(jīng)被花屏、閃屏折磨了幾天的老手看完應(yīng)該都能建立一套自己的調(diào)試思路。1. 為什么顯示驅(qū)動(dòng)調(diào)試極其依賴(lài)工具搞顯示驅(qū)動(dòng)和搞其他內(nèi)核驅(qū)動(dòng)最大的區(qū)別是大部分情況下你根本看不到代碼在哪一步出錯(cuò)。網(wǎng)絡(luò)驅(qū)動(dòng)出問(wèn)題你還能 ping 一下、看個(gè)丟包率存儲(chǔ)驅(qū)動(dòng)出錯(cuò)IO 統(tǒng)計(jì)直接給你答案。但顯示驅(qū)動(dòng)一旦出問(wèn)題現(xiàn)象往往只有幾種黑屏、白屏、花屏、閃屏、偏色。屏幕上顯示的那幾個(gè)像素根本不會(huì)告訴你“我是因?yàn)闀r(shí)序不對(duì)才花掉的”。所以做顯示驅(qū)動(dòng)基本上就是“黑盒調(diào)試”你只能靠外部工具去觀察每一個(gè)環(huán)節(jié)到底工作沒(méi)有。我習(xí)慣把顯示鏈路拆成四層來(lái)看層級(jí)對(duì)應(yīng)內(nèi)容出問(wèn)題時(shí)的表現(xiàn)主要工具應(yīng)用/合成層SurfaceFlinger、Wayland合成器圖層錯(cuò)亂、合成性能差dumpsys、glmark2內(nèi)核KMS層DRM驅(qū)動(dòng)、atomic配置、fb設(shè)置黑屏、分辨率錯(cuò)誤、模式設(shè)置失敗dmesg、modetest、debugfs面板控制層panel時(shí)序、背光、上下電序列白屏、閃爍、背光不亮dmesg、邏輯分析儀物理信號(hào)層MIPI/eDP信號(hào)質(zhì)量、時(shí)鐘頻率花屏、抖動(dòng)、顯示異常示波器、邏輯分析儀這類(lèi)分層思路很像網(wǎng)絡(luò)調(diào)試。用過(guò)網(wǎng)絡(luò)調(diào)試工具nc的人都知道排查網(wǎng)絡(luò)問(wèn)題先要搞清楚是鏈路層不通、IP層不通、還是應(yīng)用層的問(wèn)題顯示驅(qū)動(dòng)也是一樣的邏輯先定位到層再定位到點(diǎn)最后才去摳具體參數(shù)。換句話(huà)說(shuō)顯示驅(qū)動(dòng)調(diào)試沒(méi)有像nc那樣一個(gè)命令通吃全場(chǎng)的“萬(wàn)能工具”你能做的就是手上備齊一套工具按層去驗(yàn)證。另一個(gè)核心原因是顯示驅(qū)動(dòng)涉及的時(shí)序和狀態(tài)太多了。一個(gè)面板的點(diǎn)屏?xí)r序就有幾十個(gè)參數(shù)一個(gè)atomic commit里面涉及crtc、plane、connector三個(gè)對(duì)象的狀態(tài)聯(lián)動(dòng)?？咳庋邸白x代碼找bug”大概率會(huì)漏但工具不會(huì)騙你——它把真實(shí)硬件狀態(tài)擺在你面前比對(duì)一下就知道驅(qū)動(dòng)代碼有沒(méi)有按預(yù)期走。2. 內(nèi)核態(tài)調(diào)試工具從日志到運(yùn)行追蹤這一層是顯示驅(qū)動(dòng)調(diào)試的主戰(zhàn)場(chǎng)。內(nèi)核態(tài)的工具有個(gè)共同特點(diǎn)它們反映的是驅(qū)動(dòng)程序自身運(yùn)行時(shí)的真實(shí)狀態(tài)不是靠猜而是直接讀內(nèi)核的數(shù)據(jù)結(jié)構(gòu)、跟蹤函數(shù)的執(zhí)行軌跡。2.1 drm.debug與dynamic_debug讓內(nèi)核開(kāi)口說(shuō)話(huà)DRM源碼里到處是DRM_DEBUG、DRM_DEV_DEBUG、DRM_ATOMIC_PRINT這些打印默認(rèn)情況下這些調(diào)試信息是關(guān)閉的因?yàn)槿_(kāi)的話(huà)日志刷屏非常嚴(yán)重。你需要通過(guò)drm.debug參數(shù)來(lái)控制輸出級(jí)別。drm.debug參數(shù)是按位圖工作的比較常用的位0x01 DRM_UT_CORE核心消息0x02 DRM_UT_DRIVER驅(qū)動(dòng)通用消息0x04 DRM_UT_KMSKMS相關(guān)0x08 DRM_UT_PRIMEDMA-BUF/PRIME相關(guān)0x10 DRM_UT_ATOMICatomic操作相關(guān)0x20 DRM_UT_VBLANK垂直消隱相關(guān)0x40 DRM_UT_STATE對(duì)象狀態(tài)相關(guān)實(shí)際操作中像我排查modeset問(wèn)題會(huì)這樣加載modprobe drm drm.debug0x1f0x1f就是0x01到0x10全開(kāi)正好覆蓋了core、driver、KMS、prime、atomic。這組日志會(huì)詳細(xì)打印atomic事務(wù)中plane、crtc的更新過(guò)程是定位“為什么模式設(shè)置失敗”的第一手資料。如果內(nèi)核模塊已經(jīng)加載了也可以運(yùn)行時(shí)調(diào)echo 0x1f /sys/module/drm/parameters/debug比我更常用的是dynamic_debug機(jī)制它可以在不重啟的情況下精確打開(kāi)某個(gè)驅(qū)動(dòng)的某一類(lèi)打印echo file drivers/gpu/drm/specific_driver.c line 320 p /sys/kernel/dynamic_debug/control echo module my_display_driver p /sys/kernel/dynamic_debug/control這條命令的意思是打開(kāi)某個(gè)文件的某一行或者整個(gè)模塊的動(dòng)態(tài)打印。排查驅(qū)動(dòng)初始化流程時(shí)把module級(jí)別的打印全開(kāi)再配合dmesg看執(zhí)行順序基本能定位是probe卡死、資源申請(qǐng)失敗還是panel沒(méi)就緒?？慈罩疽灿屑记?。dmesg默認(rèn)輸出很多時(shí)候被其他日志擠掉了我會(huì)習(xí)慣性地先做一件事dmesg -c清空當(dāng)前日志然后復(fù)現(xiàn)問(wèn)題這樣后面打印出來(lái)的就是本次操作產(chǎn)生的完整日志不會(huì)混入系統(tǒng)啟動(dòng)歷史。復(fù)現(xiàn)問(wèn)題后再用dmesg回看配合時(shí)間戳和調(diào)用順序判斷執(zhí)行路徑。一個(gè)小經(jīng)驗(yàn)是顯示驅(qū)動(dòng)的初始化日志往往在啟動(dòng)階段就已經(jīng)刷過(guò)去了等到你進(jìn)系統(tǒng)發(fā)現(xiàn)問(wèn)題再來(lái)看dmesg只能看到交互階段的信息。所以真正排查初始化問(wèn)題時(shí)要在啟動(dòng)參數(shù)里加上loglevel8并且用串口或內(nèi)核日志抓取工具把啟動(dòng)過(guò)程全程記錄下來(lái)。2.2 /sys/kernel/debug/dri文件系統(tǒng)直接讀驅(qū)動(dòng)內(nèi)部狀態(tài)dmesg是“驅(qū)動(dòng)主動(dòng)告訴你發(fā)生了什么”而debugfs下的文件是“你自己去看當(dāng)前驅(qū)動(dòng)是什么狀態(tài)”。后者在排查問(wèn)題的時(shí)候往往更硬核因?yàn)樗苯臃从硟?nèi)核對(duì)象在某一時(shí)刻的真實(shí)取值。先掛載debugfsmount -t debugfs none /sys/kernel/debug然后進(jìn)到DRM相關(guān)目錄cd /sys/kernel/debug/dri/0 ls里面會(huì)有state、framebuffers、connectors、clients等一堆文件。我最?？吹氖莝tate它會(huì)把這個(gè)DRM設(shè)備下所有對(duì)象的狀態(tài)完整打印出來(lái)包括crtc的enable/active狀態(tài)、當(dāng)前mode、plane的fb關(guān)聯(lián)、connector的連接狀態(tài)。算是“一鍵查看驅(qū)動(dòng)全家桶狀態(tài)”。舉個(gè)例子排查黑屏?xí)r需要確認(rèn)crtc到底有沒(méi)有被正確使能直接看state文件里的內(nèi)容cat /sys/kernel/debug/dri/0/state輸出里會(huì)看到類(lèi)似這樣的關(guān)鍵信息crtc是enabled還是disabled、active是1還是0、connector是否connected。如果應(yīng)用層和內(nèi)核都認(rèn)為crtc是enable的但屏幕依然黑屏那問(wèn)題就不在KMS狀態(tài)配置上而是要去查panel本身的上電時(shí)序和信號(hào)輸出。這個(gè)判斷在調(diào)試中省了我大量時(shí)間因?yàn)樗苤苯影选膀?qū)動(dòng)狀態(tài)沒(méi)問(wèn)題”這一塊排除掉。framebuffers文件也很有用cat /sys/kernel/debug/dri/0/framebuffers它會(huì)列出當(dāng)前創(chuàng)建的framebuffer對(duì)象包括句柄、寬度、高度、stride行字節(jié)數(shù)、像素格式。很多花屏問(wèn)題追到最后就是stride計(jì)算不匹配。比如用戶(hù)空間應(yīng)用按1080寬、每像素4字節(jié)對(duì)齊生成了4420字節(jié)的stride驅(qū)動(dòng)卻按4320字節(jié)去計(jì)算掃描地址那從第二行開(kāi)始就會(huì)錯(cuò)位表現(xiàn)出來(lái)就是肉眼可見(jiàn)的花屏條紋。這類(lèi)問(wèn)題從debugfs里一眼就能看出來(lái)。2.3 ftrace與perf把驅(qū)動(dòng)運(yùn)行軌跡錄下來(lái)dmesg和debugfs能看到“是什么狀態(tài)”但想看“執(zhí)行了哪些函數(shù)、耗時(shí)多少”就得靠ftrace和perf這兩個(gè)性能與追蹤大殺器。我排查驅(qū)動(dòng)長(zhǎng)時(shí)間才點(diǎn)亮屏幕的問(wèn)題時(shí)最常用的就是ftrace的函數(shù)圖模式echo 0 /sys/kernel/debug/tracing/tracing_on echo function_graph /sys/kernel/debug/tracing/current_tracer echo drm_atomic_commit_tail /sys/kernel/debug/tracing/set_graph_function echo 1 /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace這段操作的意思是打開(kāi)function_graph追蹤只追蹤drm_atomic_commit_tail這個(gè)函數(shù)及其調(diào)用的子函數(shù)然后讀取追蹤結(jié)果。輸出里會(huì)看到密密麻麻的函數(shù)調(diào)用縮進(jìn)能直觀看出內(nèi)核在哪個(gè)子函數(shù)里消耗了大量時(shí)間。用trace-cmd更省事trace-cmd record -p function_graph -l drm_atomic* trace-cmd reporttrace-cmd會(huì)自動(dòng)管理追蹤緩沖區(qū)的開(kāi)關(guān)和讀取比手寫(xiě)echo命令可維護(hù)性強(qiáng)得多。我一般會(huì)配合一個(gè)小腳本把重復(fù)的trace流程自動(dòng)化思路有點(diǎn)像寫(xiě)lua腳本去批量執(zhí)行調(diào)試操作——把固定的操作序列固化成腳本然后每次復(fù)現(xiàn)問(wèn)題時(shí)只改目標(biāo)函數(shù)名節(jié)省下來(lái)的時(shí)間很可觀。perf在大規(guī)模耗時(shí)分析上更強(qiáng)。比如驅(qū)動(dòng)整體性能下降用perf找熱點(diǎn)函數(shù)是最快的perf top這個(gè)命令會(huì)實(shí)時(shí)顯示CPU使用率最高的內(nèi)核函數(shù)。如果看到某個(gè)鎖函數(shù)、某個(gè)list遍歷函數(shù)占了很高的比例那性能問(wèn)題大概率就在那里。做顯示驅(qū)動(dòng)性能調(diào)優(yōu)時(shí)我還會(huì)用perf record抓一段實(shí)際點(diǎn)屏或刷屏的調(diào)用鏈再通過(guò)perf report看annotate視圖。很多“屏幕刷新一卡一卡”的問(wèn)題最后都是通過(guò)這個(gè)方式定位到驅(qū)動(dòng)里某個(gè)不必要的忙等待循環(huán)。3. 用戶(hù)態(tài)測(cè)試工具驗(yàn)證鏈路功能內(nèi)核態(tài)工具解決“驅(qū)動(dòng)有沒(méi)有按預(yù)想工作”的問(wèn)題用戶(hù)態(tài)工具解決的是“整個(gè)顯示鏈路能不能跑通、跑得多快”的問(wèn)題。這是兩條腿缺一條都不行。3.1 modetestKMS功能的照妖鏡modetest是libdrm目錄下的經(jīng)典測(cè)試工具凡是做Linux顯示驅(qū)動(dòng)的人一定都認(rèn)識(shí)它。它用最樸素的方式調(diào)用DRM KMS接口把當(dāng)前的connector、encoder、crtc、plane信息全部枚舉出來(lái)這在驗(yàn)證顯示驅(qū)動(dòng)最基本功能時(shí)極其有用。先看基礎(chǔ)用法# 查看card0下所有connector的狀態(tài) modetest -M card0 -c # 查看所有plane及其支持的像素格式 modetest -M card0 -p # 在connector 32上設(shè)置一個(gè)1080x192060Hz的模式 modetest -M card0 -s 32:1080x1920-60-c參數(shù)輸出每個(gè)connector的連接狀態(tài)、物理尺寸、支持的mode列表。如果內(nèi)核已經(jīng)成功解析了EDID或者panel驅(qū)動(dòng)里預(yù)設(shè)了mode這里就能看到mode列表。如果這個(gè)列表是空的說(shuō)明驅(qū)動(dòng)沒(méi)有正確向KMS暴露模式屏幕當(dāng)然點(diǎn)不亮。-p參數(shù)會(huì)列出所有plane的尺寸范圍、格式列表和當(dāng)前關(guān)聯(lián)的fb是排查花屏問(wèn)題的重要入口。最硬核的用法是直接在屏幕上輸出測(cè)試彩條modetest -M card0 -s 32:1080x1920 -v這個(gè)命令在目標(biāo)connector上創(chuàng)建一個(gè)framebuffer用一段動(dòng)態(tài)變化的彩條填充并輸出。如果你能看到流暢變化的彩條說(shuō)明從KMS到panel整條鏈路沒(méi)有任何問(wèn)題剩下的問(wèn)題就出在應(yīng)用或合成層。如果彩條是花的、錯(cuò)位的、或者根本沒(méi)畫(huà)面那就回頭去查內(nèi)核態(tài)。有臺(tái)式機(jī)環(huán)境跑modetest時(shí)有個(gè)注意點(diǎn)如果X/Wayland正占著顯卡modetest會(huì)拿不到設(shè)備。最簡(jiǎn)單的辦法是切到純文本終端下執(zhí)行或者用DRM主設(shè)備權(quán)限直接跑。很多新手說(shuō)modetest沒(méi)輸出排查一番后發(fā)現(xiàn)是權(quán)限問(wèn)題。用root或者把用戶(hù)加入video組可以避免絕大部分權(quán)限坑。3.2 kmscube與glmark2從GPU到屏幕的完整鏈路modetest驗(yàn)證的是“不經(jīng)過(guò)GPU、直接KMS輸出”的鏈路但很多花屏、撕裂問(wèn)題是GPU渲染和顯示掃描之間的配合出了問(wèn)題。這時(shí)候需要kmscube和glmark2這類(lèi)工具拉通全鏈路驗(yàn)證。kmscube在支持EGL/GLE的平臺(tái)上跑一個(gè)旋轉(zhuǎn)的立方體場(chǎng)景同時(shí)會(huì)把渲染結(jié)果通過(guò)KMS直接提交到顯示層。它既能驗(yàn)證GPU能不能正常渲染又能驗(yàn)證渲染結(jié)果能不能正確顯示。我在排查“GPU渲染輸出后屏幕顯示空白”這類(lèi)現(xiàn)象時(shí)第一個(gè)跑的就是kmscube。它能幫我快速區(qū)分是GPU沒(méi)有渲染出內(nèi)容還是渲染出來(lái)了但沒(méi)有被正確掃描出。glmark2則是標(biāo)準(zhǔn)OpenGL ES基準(zhǔn)測(cè)試工具它跑的是大量場(chǎng)景組合測(cè)完會(huì)給出一個(gè)綜合幀率和每項(xiàng)得分。對(duì)顯示驅(qū)動(dòng)調(diào)試來(lái)說(shuō)glmark2的價(jià)值在于壓力測(cè)試和性能基線(xiàn)如果幀率明顯低于正常水平或者畫(huà)面在切換場(chǎng)景時(shí)出現(xiàn)撕裂那就是驅(qū)動(dòng)性能優(yōu)化不到位的信號(hào)。配套的還有一個(gè)eglinfo工具eglinfo它能輸出EGL版本、擴(kuò)展列表、surface格式、原生窗口類(lèi)型等。排查EGL配置時(shí)很有用尤其是確認(rèn)默認(rèn)surface格式是不是被工作負(fù)載意外改了。比如某個(gè)app跑完后EGL surface格式從RGBA8888變成RGB565就會(huì)導(dǎo)致畫(huà)面顏色發(fā)紫或閃一下這個(gè)狀態(tài)用eglinfo查一遍馬上就能確認(rèn)。3.3 邏輯分析儀與示波器物理層最后一道防線(xiàn)內(nèi)核態(tài)和用戶(hù)態(tài)工具都查完了問(wèn)題還是存在那就說(shuō)明大概率是物理信號(hào)層面的問(wèn)題。這時(shí)候必須上硬件工具邏輯分析儀用來(lái)抓MIPI DSI、eDP的包命令和時(shí)序示波器用來(lái)量時(shí)鐘頻率、上升沿質(zhì)量和電壓幅值。用邏輯分析儀抓屏過(guò)程最核心的是確認(rèn)一點(diǎn)panel初始化序列到底有沒(méi)有按預(yù)期發(fā)出去。我調(diào)試一塊MIPI DSI屏?xí)r屏幕白屏但背光亮內(nèi)核日志顯示panel驅(qū)動(dòng)probe正常。這時(shí)我接上邏輯分析儀抓取MIPI DSI的command lane發(fā)現(xiàn)驅(qū)動(dòng)根本沒(méi)有往panel發(fā)送display on指令因?yàn)閞eset GPIO的時(shí)序反了panel一直停留在sleep模式。這個(gè)問(wèn)題從日志上看完全無(wú)解只靠邏輯分析儀抓波形才能定位。示波器主要用于測(cè)量時(shí)鐘頻率和信號(hào)質(zhì)量。點(diǎn)屏后如果屏幕閃得很厲害優(yōu)先用示波器量一下pixel clock或MIPI clock的實(shí)際頻率。很多時(shí)候驅(qū)動(dòng)里配置的頻率和PLL實(shí)際算出來(lái)的頻率不一致導(dǎo)致刷新率偏移你以為是驅(qū)動(dòng)導(dǎo)致閃屏實(shí)際上是時(shí)鐘參數(shù)算錯(cuò)了。測(cè)量要點(diǎn)是直接在時(shí)鐘lane上量頻率然后反推刷新率和modetest里設(shè)置的模式做比對(duì)相差在1%以?xún)?nèi)才算正常。4. 實(shí)操一次花屏問(wèn)題的完整排查路徑工具講再多都是紙面功夫真正有價(jià)值的是把工具串起來(lái)的實(shí)戰(zhàn)流程。我拿最近調(diào)試的一塊1080x1920 RGB LCD屏為例完整走一遍排查思路你可以直接參考這個(gè)路徑?，F(xiàn)象是內(nèi)核啟動(dòng)到顯示階段后屏幕有畫(huà)面但畫(huà)面明顯花屏表現(xiàn)為橫向彩色條紋每隔一段距離就錯(cuò)位一次。這是顯示驅(qū)動(dòng)調(diào)試?yán)锓浅５湫偷陌Y狀——數(shù)據(jù)有輸出但幀緩沖被錯(cuò)誤掃描了。第一步看內(nèi)核日志確認(rèn)驅(qū)動(dòng)有沒(méi)有報(bào)錯(cuò)dmesg | grep -i drm排查結(jié)果沒(méi)有任何error/warning級(jí)別的信息驅(qū)動(dòng)probe成功panel也正常初始化。這說(shuō)明問(wèn)題不在于驅(qū)動(dòng)崩潰或panel沒(méi)起來(lái)。第二步用modetest確認(rèn)KMS對(duì)象狀態(tài)modetest -M card0 -c modetest -M card0 -p查出connector狀態(tài)正常mode列表里有1080x192060plane也處于正常狀態(tài)。這說(shuō)明KMS層的模式配置是通的。此時(shí)我心里已經(jīng)有一半把握問(wèn)題出在plane和framebuffer的尺寸/stride匹配上。第三步直接看debugfs確認(rèn)framebuffer的真實(shí)參數(shù)cat /sys/kernel/debug/dri/0/framebuffers重點(diǎn)看stride和pixel_format兩個(gè)字段。對(duì)比modetest輸出后發(fā)現(xiàn)實(shí)際framebuffer的stride是4420字節(jié)而plane配置時(shí)計(jì)算出來(lái)的stride值卻是4320字節(jié)。兩者差了正好100字節(jié)每行。這樣每掃描一行地址就會(huì)往后偏移100字節(jié)掃描到屏幕中間就會(huì)累積出一大截錯(cuò)位看起來(lái)就是橫向條紋花屏。第四步反向追蹤stride為什么不對(duì)。檢查應(yīng)用層的buffer分配邏輯發(fā)現(xiàn)它按1080寬度乘以一個(gè)不當(dāng)?shù)腶lignment硬編碼了stride而KMS驅(qū)動(dòng)的atomic check里沒(méi)有校驗(yàn)stride是否匹配導(dǎo)致錯(cuò)誤配置一路綠燈直到顯示。修復(fù)方式是在atomic_check中增加stride一致性校驗(yàn)同時(shí)修正應(yīng)用層的分配代碼。這個(gè)過(guò)程看起來(lái)簡(jiǎn)單但如果沒(méi)有第二步和第三步的工具支撐我大概只能靠反復(fù)改驅(qū)動(dòng)打印來(lái)定位那會(huì)慢得多。調(diào)試工具的意義就在于此每一步都能直接排除一類(lèi)可能逐步縮小范圍到具體對(duì)象。我復(fù)盤(pán)時(shí)總跟新人說(shuō)花屏問(wèn)題先還原到“KMS輸出彩條”這一步如果是彩條也花就說(shuō)明問(wèn)題在驅(qū)動(dòng)或物理鏈路如果彩條正常就去看應(yīng)用層buffer。這條分界的價(jià)值極高能讓你少走一半彎路。5. 常見(jiàn)問(wèn)題速查表與排查技巧實(shí)錄做多了顯示驅(qū)動(dòng)調(diào)試發(fā)現(xiàn)很多問(wèn)題是有規(guī)律可循的。我把這些年積累的問(wèn)題現(xiàn)象、排查路徑和對(duì)應(yīng)工具整理成一張速查表遇到問(wèn)題直接對(duì)照著查現(xiàn)象優(yōu)先排查路徑關(guān)鍵工具黑屏無(wú)背光背光控制GPIO/PWM是否配置、背光供電時(shí)序dmesg、示波器黑屏有背光panel上下電時(shí)序、reset/STB引腳電平、初始化命令邏輯分析儀、dmesg白屏panel是否進(jìn)入sleep模式、display on是否發(fā)出邏輯分析儀花屏錯(cuò)位fb的stride/pixel_format/地址對(duì)齊debugfs、modetest花屏雪花MIPI lane數(shù)配置、clock頻率邏輯分析儀、示波器閃屏刷新率是否正確、vblank中斷是否穩(wěn)定modetest、ftrace、示波器偏色pixel_format、色域空間、clutmodetest、debugfs撕裂vsync等待缺失、buffer切換不同步glmark2、dmesg觸摸時(shí)畫(huà)面卡中斷優(yōu)先級(jí)、共享鎖競(jìng)爭(zhēng)perf、ftrace排查時(shí)的幾個(gè)核心技巧值得單獨(dú)寫(xiě)出來(lái)首先復(fù)現(xiàn)問(wèn)題時(shí)一定要保留現(xiàn)場(chǎng)日志。drm.debug全開(kāi)后再去復(fù)現(xiàn)問(wèn)題不要復(fù)現(xiàn)完才想起來(lái)沒(méi)開(kāi)日志。另外很多顯示問(wèn)題需要冷啟動(dòng)才能復(fù)現(xiàn)一定要在開(kāi)機(jī)日志里抓到關(guān)鍵信息否則就白跑一次。其次先用軟件工具排除軟件問(wèn)題再動(dòng)硬件工具。每次看到花屏就去接示波器這是最大的誤區(qū)。正確的順序是dmesg看錯(cuò)誤、modetest看狀態(tài)、debugfs看對(duì)象、ftrace看調(diào)用鏈最后才是接邏輯分析儀量波形。很多軟件問(wèn)題在前三步就能定位。第三改mode之前先備份當(dāng)前配置。尤其帶EDID的屏在調(diào)試時(shí)隨意切換一個(gè)錯(cuò)誤模式可能觸發(fā)面板保護(hù)。我之前調(diào)試時(shí)在連接狀態(tài)下設(shè)置了一個(gè)不支持的timing結(jié)果面板直接進(jìn)入了保護(hù)狀態(tài)需要斷電一段時(shí)間才能恢復(fù)。第四關(guān)注fb的對(duì)齊規(guī)則。DRM驅(qū)動(dòng)對(duì)framebuffer的stride和起始地址一般有對(duì)齊要求常見(jiàn)的是64位或者256字節(jié)對(duì)齊。用戶(hù)空間分配buffer的alignment若不滿(mǎn)足驅(qū)動(dòng)要求掃描就會(huì)出現(xiàn)周期性的錯(cuò)位。debugfs里看到的stride與實(shí)際分配buffer的size對(duì)不上基本就是這個(gè)原因。第五分清vblank和vsync。vblank是硬件事件vsync是vblank同步到用戶(hù)空間后的邏輯?？磀mesg里vblank中斷的頻率如果中斷頻繁丟失或者觸發(fā)異常那就不是應(yīng)用層vsync的問(wèn)題而是內(nèi)核驅(qū)動(dòng)對(duì)vblank處理有bug。很多幀率上不去的問(wèn)題追到后來(lái)都是vblank中斷被關(guān)掉了。6. 一些調(diào)試環(huán)境方面的細(xì)節(jié)補(bǔ)充工具選好了、流程理順了調(diào)試環(huán)境本身也有不少講究。我最早做調(diào)試時(shí)吃過(guò)不少虧這里多說(shuō)幾句。建議搞一整套穩(wěn)定的串口日志方案。顯示驅(qū)動(dòng)和別的驅(qū)動(dòng)不同屏幕本身就是被調(diào)試對(duì)象你沒(méi)法在屏幕上打印信息觀察系統(tǒng)狀態(tài)。如果板子沒(méi)有串口或者串口沒(méi)引出調(diào)試效率會(huì)直線(xiàn)下降。所以我做顯示驅(qū)動(dòng)開(kāi)發(fā)時(shí)第一件事就是把串口拉通而且日志級(jí)別開(kāi)到最高確保無(wú)論屏幕亮不亮都能看到內(nèi)核的完整運(yùn)行過(guò)程。另外手邊要有一套穩(wěn)定的測(cè)試畫(huà)面。我會(huì)準(zhǔn)備幾個(gè)原始色彩畫(huà)面純色、漸變、網(wǎng)格用腳本固定輸出到指定分辨率。這些畫(huà)面的好處是純色能看出屏有沒(méi)有壞點(diǎn)、偏色漸變能看出8bit/10bit色深切換是否正確網(wǎng)格能精確判斷錯(cuò)位在屏幕的哪個(gè)區(qū)域。比隨便放一張照片再觀察“看起來(lái)不對(duì)勁”要可靠得多。調(diào)試工具的自動(dòng)化腳本也值得投入時(shí)間。顯示驅(qū)動(dòng)調(diào)試經(jīng)常需要反復(fù)切換分辨率、檢查狀態(tài)、比對(duì)日志。把這些操作寫(xiě)成shell腳本或者用python腳本調(diào)用modetest和debugfs自動(dòng)比對(duì)預(yù)期結(jié)果可以解放大量重復(fù)勞動(dòng)。就像寫(xiě)lua調(diào)試腳本一樣把操作序列固化下來(lái)出問(wèn)題跑一遍就能得到結(jié)構(gòu)化結(jié)果比手動(dòng)一條條敲命令高效得多。最后聊一下工具版本的匹配問(wèn)題。modetest和debugfs接口在不同內(nèi)核版本上差異不小老內(nèi)核的modetest拿到新內(nèi)核上跑可能解析不了新的DRM對(duì)象類(lèi)型。我用的一直是隨內(nèi)核版本配套的libdrm工具盡量保持工具版本和內(nèi)核版本一致避免因?yàn)楣ぞ弑旧斫馕鲥e(cuò)誤產(chǎn)生誤導(dǎo)。畢竟調(diào)試工具自己如果不可靠它給出的結(jié)論也就不可信了?；仡^說(shuō)一點(diǎn)個(gè)人體會(huì)。我見(jiàn)過(guò)很多人桌上堆滿(mǎn)了高端示波器和邏輯分析儀遇到顯示問(wèn)題卻還是兩眼一抹黑。工具的多少?gòu)膩?lái)不等于調(diào)試能力強(qiáng)真正的差距在于你有沒(méi)有建立一套“分層定位”的思維。先把問(wèn)題框到某一個(gè)層再用這一層對(duì)應(yīng)的工具去細(xì)化最后才回到代碼層面改東西。這套方法論內(nèi)化之后你會(huì)發(fā)現(xiàn)顯示驅(qū)動(dòng)調(diào)試其實(shí)沒(méi)有那么多玄學(xué)大部分問(wèn)題都是“工具用對(duì)了答案自己就出來(lái)了”。顯示器亮起來(lái)的那一瞬間永遠(yuǎn)是我做這塊驅(qū)動(dòng)最爽的時(shí)刻。而為了那一次點(diǎn)亮前面無(wú)數(shù)次把dmesg翻到底、把modetest輸出對(duì)齊、把波形量到小數(shù)點(diǎn)后幾位——這些功夫一點(diǎn)都不會(huì)白費(fèi)。