这周又被MIPI DSI摁在工位上磨了两天。起因是手里这块T527板子上接了一块1080×1920的MIPI液晶模组兴致勃勃把DTS配好结果一上电就是一片白。按说MIPI DSI点屏这事儿我干过不少回可换一块SoC、换一套BSP坑位完全不一样。这篇是BSP调试系列的第11篇我把从零开始点MIPI DSI屏的完整过程、中间踩的坑、以及最后沉淀下来的复盘清单都摊开讲。内容主要面向刚接手BSP显示调试、或者正在跟T527/类似全志平台的MIPI屏较劲的兄弟老手也可以看看很多细节其实跟平台无关。1. 先把T527的DSI链路和显示拓扑说清楚1.1 一条像素从内存到模组到底要过哪几级很多新手上来就改panel节点改完发现不亮于是怀疑初始化命令写错了。其实MIPI DSI点屏远不止往屏里写几条命令这么简单。大家先在心里建立一条完整的链路内核framebuffer里存好的图像数据先被DEDisplay Engine显示引擎取出来做合成和缩放合成结果按设定的时序送给TCON时序控制器。TCON把像素流按行场同步信号排好交给DSI Controller。DSI Controller把像素和命令打包成符合MIPI DSI规范的数据包再送进DSI PHY转成高速差分信号最后通过FPC排线到模组的TCON模组内部再把串行数据解出来驱动液晶。也就是说一个像素要经过DE → TCON → DSI Controller → DSI PHY → 模组TCON → 面板六级。任何一级没配好最终的观感都是不亮或者花屏但出问题的层次完全不同。T527这颗SoC显示能力在今天的工规板卡里属于比较能打的支持双路独立显示DSI控制器有0和1两个通路单路走4-lane是很常规的操作。我手上这块板子用的是DSI0直连模组DSI1留给了板载HDMI桥接方案。这种拓扑在T527的客户方案里非常典型——一条MIPI直出面板另一条通过转换芯片出大屏或者副屏。1.2 驱动侧的两个入口DRM框架与老disp2并存软件层面先确认你调的是哪套显示框架。我手上这套T527的BSP基于5.15内核显示驱动已经切到了DRM/KMSpanel驱动挂在drivers/gpu/drm/panel/下面DSI host控制器在drivers/gpu/drm/sunxi/里。但全志的历史包袱很重很多老项目用的还是drivers/video/fbdev/sunxi/disp2这套老disp驱动两套代码在树里并存也很常见。判断方法很简单进内核菜单看CONFIG_DRM_SUNXI还是CONFIG_FB_SUNXI开了哪个再不行就看开机日志里打印的是sunxi_drm还是disp。这里想强调一个经验不管你拿到的是哪套框架排查思路完全一样只是调试节点的名字不一样。我在T527上实际是DRM框架下去查drm_panel_attach、panel_probe这些日志但你如果拿到的SDK还是老disp2就去搜disp_lcd_probe、disp_dsi_probe症状和根因是共通的。2. 点屏前先做的三笔数学题分辨率时序、像素时钟和MIPI速率2.1 用画面空白区把pclk算出来改DTS之前一定要先算参数否则后面所有排查都是在碰运气。以我这块1080×192060Hz的模组为例第一步是确定完整的行场时序注意这里用的是带blanking的total值不是简单的分辨率乘刷新率。我用的时序是这样一组单位像素参数数值说明Hactive1080有效水平像素Hsync4行同步脉宽HBP60行后肩HFP60行前肩Htotal1204108046060Vactive1920有效垂直像素Vsync4场同步脉宽VBP20场后肩VFP20场前肩Vtotal1964192042020pclk的计算公式是pclk Htotal × Vtotal × fps 1204 × 1964 × 60 ≈ 141.88MHz很多工程师直接把面板datasheet里标的典型pclk比如140M填进lcd_dclk_freq点出来发现帧率不对或者显示区域偏移。原因就在于是不是先用你的blanking把pclk算准。pclk不是模组厂商给的固定值而是由你的行场时序决定的结果。2.2 MIPI lane速率的计算式以及PLL怎么选有了pclk第二步算每条lane的速率。DSI传输时像素数据被拆分到各条lane上并行发RGB888是24bit4-lane情况下lane_rate pclk × bpp ÷ lane_count 141.88M × 24 ÷ 4 ≈ 851.3Mbps/lane byte_clk lane_rate ÷ 8 ≈ 106.4MHzbyte_clk是TCON/DSI Controller内部处理用的字节时钟PHY则把每个字节串化成8个bit打出去。851M这条速率在一个非常安全的中段区间大部分面板PHY都能稳定扛住。真正麻烦的是时钟框架怎么把主PLL摆到851M附近。T527的CCU会给DSI控制器提供一路专用时钟通常来自某个可配置的PLL。问题在于PLL一般不是连续分频而是有一组固定的倍频/分频组合你想要的106.4MHz的byte_clk不一定能精确到达只能取一个最接近的档位。我当时的处理办法是先让驱动把候选的频率dump出来然后微调HBP/HFP让pclk落在PLL容易凑整的区间。比如把HBP从60改成68Htotal变成1212pclk变成1212×1964×60≈142.8MHzlane_rate变成856.8Mbyte_clk就是107.1M。如果PLL正好支持107.1M那比硬逼着PLL出106.4M要稳得多。改时序去迁就PLL比逼PLL出精确频率更实际。2.3 面板手册缺参数时的兜底办法现实里经常拿不到完整面板手册尤其是从方案商手里抠回来的模组就给你一页PDF连CABC怎么关都不写。这时候我会按这个顺序兜底搜内核里已有的panel driver看有没有兼容型号很多模组是公板的套壳驱动直接复用。去翻同尺寸同分辨率的其他面板规格书把blanking抄过来。1080×192060的面板Htotal在1200~1250之间基本都是合理的差别不会太大。全志社区和方案商那里一般有一份panel ini或者参考DTS比对着抄参数。实在没有就先用标准值点亮Hsync4HBP60HFP60VBP20VFP20。这个组合对绝大多数60Hz面板都友好点亮后再返回来校正。记住一个原则先点亮再校时序。画面偏几个像素、刷新率差0.5Hz不影响你判断链路是否打通但参数一上来就很离谱你可能连问题是出在驱动还是出在时序都分不清。3. 第一次上电的实战记录从无响应到出图的完整排查链路3.1 dmesg里如何快速确认DSI host有没有看到面板面板探针失败是MIPI点屏最经典的第一道坎。我这次在T527上的现场症状就是背光亮了屏幕纯白dmesg里没有明显的panic但就是没有图像。我第一件事是抓panel和dsi host的probe日志dmesg | grep -iE panel|dsi|drm | tail -80正常状态下应该能看到panel驱动的probe成功信息以及在DSI host注册时panel被attach到某个connector上。如果看到的是panel-xxx: probe failed或者干脆没有这段日志那就是链路根本没建立起来。这时候按顺序排查三件事compatible字符串是否匹配。panel节点里的compatible跟驱动里of_device_id对不上驱动不会加载这是最低级的错误但是出现率最高。endpoint是否连到了DSI controller。T527的DSI0节点下有个port子节点端点和panel的端点必须通过remote-endpoint互相指向少写一边就是光棍状态。clock是否给了。DSI host需要一路自己的时钟源DTS里clocks和assigned-clock-rates必须配好。没时钟的DSI controller连读写寄存器都不一定报错但就是出不了信号。3.2 一个GPIO复用冲突硬生生把点屏拖了三天这次最难缠的问题不是DSI本身而是reset脚被占。T527的引脚复用极其灵活灵活到你在pinctrl里配的功能和别的驱动抢同一个物理引脚时连个警告都可能没有。现象是panel probe偶尔成功偶尔失败失败时dmesg里就一行pin PC5 already requested之类的提示。最开始我以为GPIO编号写错了反复对原理图PC5就是reset没错。后来查/sys/kernel/debug/gpio发现PC5被板上的另一个外设驱动以default状态占用了两个驱动都没有显式冲突但pinctrl子系统只允许一个owner后加载的disp直接拿不到引脚。排查方法也分享给大家cat /sys/kernel/debug/gpio cat /sys/kernel/debug/pinctrl/pinctrl-handles查完就知道哪个驱动占了哪些引脚。我当时把占用驱动在DTS里改成status disabled验证reset脚释放后DSI链路立刻通了。GPIO复用冲突不会像电压不对那样让你一眼看出它更像是一个时好时坏的阴间故障遇到探针间歇性失败优先查引脚占用。3.3 复位时序和初始化命令序列宁可慢不要快数据链路通了之后接着就是面板自身的初始化和复位时序。T527的panel驱动里上电时序大致是模组供电先上来延时10~20msRESET拉低保持至少1ms再拉高然后延时20~120ms不等才能发初始化命令。很多面板对时序的宽容度很差尤其是带内部TCON的模组。我遇到过一个典型casereset高电平后只延时了5ms就去发DCS命令结果屏一直白。排查了很久后来把延时拉到50ms画面直接出来。时序遵循的是模组厂商手册的时序参数多数情况大一点更安全。初始化命令本身也有一些容易踩的细节。DSI的DCS命令分短包0x05/0x15和长包0x29/0x39短包适合发不带参数的命令比如Display On长包适合发一串数据比如设寄存器值。Panel驱动里一般会给你一个带delay的初始化数组格式类似数据长度 命令 payload 延时static const struct panel_init_cmd hx8394_init_cmds[] { {0x23, {0xB9, 0xFF, 0x83, 0x94}, 0}, // 设置寄存器 page {0x30, {0xB1, 0x02, 0x00, 0x34, ...}, 10}, // 带10ms延时 {0x05, {0x11}, 120}, // Sleep Out等120ms {0x05, {0x29}, 50}, // Display On等50ms };注意区分数据头前面的长度字节这个长度是命令payload的总字节数不是payload长度写错了整个数组解析就会偏。还有一点我想强调背光要在面板初始化完成之后再打开。先开背光只会让你盯着一个白屏或闪屏干瞪眼还会掩盖真正的问题。我当时把背光使能放到panel驱动probe成功、init命令发完之后排错时至少能通过背光和画面的先后关系判断进度。4. 亮屏只是及格线花屏、闪屏、撕裂的分诊手册4.1 白屏、花屏、横向滚动的根因别搞混T527上把画面点亮之后事情才刚开始。各种显示异常症状的根因完全不同我列个分诊表后面照着对现象大概率原因优先排查方向背光亮、屏幕全白面板未初始化成功 / video mode没生效reset时序、panel init命令、DSI时钟花屏雪花噪点lane速率不对 / EOTP不匹配 / 极性反重新算lane_rate、改EOTP开关图像只有上半屏/下半屏错位blanking不够burst模式下数据发不完加大HBP/HFP画面横向滚动撕裂帧同步信号不对 / command mode没接TE查TE脚、改video mode右边一条亮线或拖尾HBP太小 / 每行末尾丢包加大HBP、调EOTP低亮度下可见波纹闪烁PHY驱动强度/摆率不匹配调PHY参数、检查等长走线这表不是绝对真理但排查顺序非常关键。先判断是没有信号还是信号不对再去动寄存器能少走很多弯路。4.2 blanking、EOTP和TE这三个小参数为什么能要命这三个参数在DTS里往往就一行但酿成的惨案一个比一个多。先说blanking。DSI video mode下每发完一行有效像素DSI Controller要在行blanking期间做一些协议维护工作比如发送同步包、让PHY回到LP状态等。如果你的HBP/HFP太小整个行周期不够就会变成这一行还没发完下一行已经到了表现出来就是画面在下半部分错位、撕裂甚至整屏滚动。可以做一个简单核算。刚才的例子中一行总时间是line_time Htotal ÷ pclk 1204 ÷ 141.88M ≈ 8.49us传输一行有效像素数据的时间是transmit_time (Hactive × bpp) ÷ (lane_count × 8 × byte_clk) (1080 × 24 ÷ 32) ÷ 106.4M 810 byte ÷ 106.4M ≈ 7.62us8.49us减去7.62us只剩0.87us给DSI协议开销。这个值非常紧实际跑起来还受PHY初始化、命令包、EOTP尾包占用时间影响所以HBP/HFP千万不要往小了调60这个值在1080P的面板上是底线附近再小就等着出事。EOTP是End of Transmission Packet很多面板对这个包的期望值和发送端不一致。有些屏必须关掉EOTP否则每行末尾会出现一条垂直方向的暗线或者噪点有些屏必须开着否则PHY进入LP状态时机不对。T527的DTS里有对应的开关属性一般默认关。遇到边缘竖线右侧拖尾这类只出现在画面边界的故障先切换EOTP开关试试成本极低。TETearing Effect信号则是帧同步问题。如果你用的是command mode比如部分半反半透屏或者墨水屏TE脚必须接否则模组的内部刷新和SoC送数据不同步画面会像被撕开一样分成两半。如果用的是video modeTE一般不是必选但有些面板依然需要SoC按TE脉冲来决定发送起始帧这时候不接TE会看到周期性的横向滚动条。判断依据很简单面板手册里如果写了TE信号就接上并按驱动要求配好如果没写先按video mode不带TE处理。4.3 像素时钟与MIPI速率不匹配的典型现象时钟误配是花屏噪点的主要来源而且表现很有迷惑性——屏幕亮度正常、能隐约看到UI轮廓但上面覆盖着一层细密雪花。我这次在T527上就遇到过。DTS里lcd_dclk_freq填了144M但实际pclk按我的blanking算出来是141.88MMIPI lane_rate自然就对不上。DSI PHY发出的bit时钟和TCON给的像素时钟不同步模组TCON只能按自己的节奏去采结果数据采得七零八落。解决办法是回到第2节的算式把两个时钟对齐。这里有个小技巧不要只改DTS里的lcd_dclk_freq就完事还要确认clk framework里给DSI controller的实际频率打印有的驱动还会做一轮四舍五入你填的数和实际用的数中间可能差着好几个档位。# 确认实际时钟不同SDK路径略有差异 cat /sys/kernel/debug/clk/clk_summary | grep -iE dsi|tcon|pll_video如果手头有示波器更直接的验证是量clock lane的HS频率跟理论lane_rate对比。误差超过2%就说明时钟树没对齐别急着调PHY阻抗先把频率校准再说。5. BSP工程师手上的三板斧实测工具与验证方法5.1 sysfs/debugfs把状态拿出来看MIPI DSI调试不能全凭肉眼要学会把状态拉出来看。T527这套BSP里常用的有三个层次。第一个层次是内核调试节点。DRM框架下modetest -M sunxi -c # 看connector状态 modetest -M sunxi -p # 看plane/overlay modetest -M sunxi -s 32:1080x192060 # 手动切分辨率老disp2体系下则是类似的# 不同SDK名称有差异但一定存在 cat /sys/class/disp/disp/attr/sys cat /proc/disp/disp_para第二个层次是时钟状态/sys/kernel/debug/clk/clk_summary这个文件能让你一眼看出DSI和TCON的时钟是否打开、频率是不是你期望的值。很多屏幕完全不亮其实是因为某个clk_disable_unused把它关了查这个文件比反复改DTS快得多。第三个层次是panel驱动的status节点。有些panel driver会在sysfs里暴露enabled/status这样的只读属性可以直接读到链接状态和电源状态。别小看这一步它能帮你把驱动问题和硬件问题在五秒内切开。5.2 寄存器dump与示波器对拍软件状态看完了就要往底层走。寄存器dump和示波器是BSP调试的一对黄金搭档。寄存器层面把DSI controller和PHY的寄存器全部dump下来和其他正常板子的dump做diff是最快的定位手段。重点关注这几类寄存器PHY状态寄存器能看出每条lane当前处于HS还是LP状态。如果data lane始终停在LP状态说明PHY根本没进入高速传输问题在时钟或者握手。PLL lock状态位DSI PHY的PLL没lock所有lane都起不来。DSI controller的fifo状态如果fifo一直满了或空着说明数据和下游的消费速率不匹配。我现在养成的习惯是拿到一块新板子先做一份黄金dump存起来。布局定型后任何显示异常都能跟这份黄金dump对比而不是临时去翻datasheet。示波器层面建议大家至少量两点clock lane的HS波形频率跟理论lane_rate对拍。这个是最硬核的时钟验证比读任何日志都靠谱。data lane从LP转HS的波形看翻转是否干净。如果出现明显的振铃或眼图没睁开就说明PHY驱动强度、摆率或者PCB等长有问题。5.3 跨板对照表同样面板在两块板上的差异定位这次T527的case里我手里恰好有一块参考板同样型号的模组是点亮状态这就给了我一个杀手锏——参数对照。下面这张表就是当时做的关键参数对比参数参考板正常故障板花屏结论lcd_dclk_freq142.8MHz144MHz主时钟不一致优先对齐lane_rate856.8Mbps864Mbps随pclk偏差异常HBP6856HBP偏小burst开销不足EOTP关闭开启行尾信号不匹配PHY drive strength默认值默认值暂不动最后的结果组合是把pclk改成142.8M、HBP改回68、EOTP关掉之后画面立刻恢复正常。跨板对照比任何调试工具都高效因为它在同一根标准答案下面找偏差。如果没有参考板也可以拿同一块板子的上一版固件做对照或者干脆对着源码里的默认config逐字段比对。6. 复盘清单和几个值得记一辈子的教训6.1 每次点屏都要过一遍的checklist把这次的完整过程沉淀成一张清单以后每块新板子点屏我都会按这个顺序走一遍不放飞任何一个环节。[ ] 确认显示链路拓扑DE、TCON、DSI Controller、PHY、面板逐级对通。[ ] 确认pclk用完整行场total自己算一遍不要直接抄datasheet典型值。[ ] 确认lane_ratepclk × bpp ÷ lane_count结果落在面板支持的速率区间。[ ] 确认时钟树DTS里clocks、assigned-clock-rates、assigned-clock-parents是否配好检查clk_summary。[ ] 确认panel compatible与panel driver的of_device_id严格一致。[ ] 确认endpointpanel与DSI host端口互指。[ ] 确认GPIOreset、backlight、TE、power enable都没有被其他驱动占用。[ ] 确认上电时序VCC → delay → RESET → delay → init command - delay → backlight。[ ] 确认初始化命令短包/长包类型正确长度字段正确命令间延时足够。[ ] 确认DSI工作模式video mode还是command modeTE是否必须。[ ] 确认blankingHBP/HFP留有足够余量burst模式下尤其不能抠门。[ ] 确认EOTP开关和模组期望一致。[ ] 界面出图后做一次时钟频率实测确认HS速率和理论值偏差在2%以内。这张清单看起来长但实际走一遍很快。真正耗时间的从来不是清单本身而是跳过某一项然后花了三天找回来。6.2 我在这块T527上踩过最痛的坑希望你别再踩印象最深的不是花屏而是那个GPIO复用冲突。它让我意识到MIPI DSI这类高速接口的BSP调试绝大多数问题的根子根本不在高速信号本身而在电源、复位、引脚这些低速环节。信号链路的异常往往是大白于天下的一量波形就知道了反倒是这些基础环节因为看起来跟显示无关最容易被人忽视。另外一句掏心窝的建议改参数一次只改一个变量。我这块T527上的花屏问题其实是pclk、HBP、EOTP三个因素叠加的结果。如果我同时改三个参数可能画面也好了但永远不知道哪个才是真凶下次换一个模组照样抓瞎。我是一步步从对照表里挑出差值最大的那个先改——先对齐主时钟再补HBP最后关EOTP每一步都验证画面变化这才把三个根因分别钉死。最后再说个实用习惯。每次点完一块屏我都会把当时的计算草稿、寄存器dump、对照表和DTS差异存成一个panel_xxx.md放到项目文档里。MIPI DSI面板看着千奇百怪但底层逻辑逃不出时序、速率、命令、同步这几件事。有了一份自己的笔记库下一次遇到相似模组你翻笔记的速度绝对比重新踩坑快得多。这个系列后面如果还遇到T527上HDMI桥接或者双屏同时出图的坑我再接着写。