MIPI DSI调过屏的人都知道这接口最烦人的地方不是协议难懂而是链路太长从framebuffer里的像素到屏幕真正点亮中间隔着显示引擎、时序控制器、DSI控制器、D-PHY、排线、面板驱动IC任何一个环节掉链子表现出来往往都是同一个结果——黑屏。这周我在全志T527上适配一块720x1280的触摸模组主控是ST7701S就被这条链路折磨了整整一天。这篇是BSP调试系列的第11篇我把整个过程做个复盘重点写三个我踩得最深的坑时钟计算想当然、deskew calibration没重视、FPC排线插接太随意。同样在全志平台上调MIPI DSI屏幕的朋友这篇文章可以当一份排错手册来用。1. 先聊这次平台T527的显示链路与调试目标1.1 T527的显示子系统结构全志T527这颗SoC单论外设丰富程度在工业物联网领域算是比较能打的显示方向同时保留了RGB并口、LVDS、eDP和MIPI DSI好几类接口。MIPI DSI主要用于中尺寸液晶模组比如7寸、10.1寸这类平板或工控屏分辨率从720x1280到1080x1920不等。在BSP层面全志的显示链路是一个很经典的流水线DEDisplay Engine负责图层合成和像素格式转换TCONTiming Controller负责输出像素时序DSI Controller负责把并行像素数据打包成DSI协议报文最后由D-PHY在物理层把报文转成一对对差分信号送出去。这块的调试节点在内核里一般以sunxi开头打开调试文件系统可以看到不少显示相关的状态。这里我特别想强调一个观点调MIPI DSI最重要的一点是先建立链路意识。一个像素从framebuffer走到屏幕上要经过合成、时序、打包、串行化、传输、解包六七个环节。出问题的时候你的第一件事不是盯着屏参数表看而是先判断这个问题出在链路的哪一段。链路意识建立起来之后排查才有方向。1.2 这次要调的ST7701S模组参数我这次拿到的模组屏厂给的规格是这样分辨率720 x 1280接口MIPI DSI4条数据lane色彩格式RGB888即24bpp面板驱动ICST7701S工作模式Video ModeBurst模式背光独立供电PWM调节ST7701S这颗IC在720x1280这个分辨率段非常常见兴唐微Sitronix的方案很多屏厂都拿它出模组。后续章节里面板驱动的部分我都以这颗IC为主线来讲。我建议任何人都别在拿到屏厂资料之前就动手写设备树。所谓资料至少有四样接口时序页含htotal/vtotal、像素时钟、命令初始化表、上下电时序图、模组规格书。少一样后面都可能埋雷。1.3 和瑞芯微那边的适配方式有什么不同网络热词里有人搜rk3588 linux 适配mipi屏幕说明瑞芯微平台调MIPI的讨论非常多。RK3588那边基本是标准DRM框架dts里挂一个panel节点panel驱动实现drm_panel的回调接口就行生态比较统一社区资料也相对好找。全志这边的情况不太一样。如果你拿到的BSP是老一些的版本显示链路可能还是传统的FBDEV框架加上私有的lcd驱动部分配置不是放在dts里而是放在sys_config.fex甚至uboot环境变量里。所以我在T527上做的第一件事不是改代码而是确认手里内核版本到底走的是哪一套框架再去决定到哪里改参数。这个确认动作能省掉大量无用功。2. 动手之前先算清楚像素时钟、lane速率与DPHY频率2.1 MIPI DSI带宽的推导关系MIPI DSI链路调参本质上只有三个数像素时钟、总带宽、单lane速率。这三个数之间有明确的公式关系像素时钟pixel_clk htotal × vtotal × refresh总带宽total_bitrate pixel_clk × bpp单lane速率lane_rate total_bitrate / lane数lane_rate是后续D-PHY配置、时钟源选择、deskew校准窗口的核心依据不能随手抄别的平台的数值必须自己算一遍。很多第一次调MIPI的朋友习惯直接从别的项目里复制一份时钟配置结果屏亮了但闪烁或者高低温下莫名花屏都是因为速率的余量和相位关系不对。2.2 720x128060Hz的完整算例我这块屏屏厂给的参数是htotal 880、vtotal 1300包含了水平垂直blank区域。代入公式pixel_clk 880 × 1300 × 60约等于68.64MHz。 total_bitrate 68.64MHz × 24bpp约等于1.65Gbps。 4条lane时lane_rate 1.65Gbps / 4约等于411.84Mbps。这里有个特别容易绕晕的细节MIPI D-PHY的时钟lane是DDR双沿采样所以时钟lane的物理频率约等于lane_rate的一半也就是206MHz附近。我去配置时钟树的时候要找的是206MHz附近合适的PLL频率点而不是直接对着411.84这个数字填。同一个项目里很多人在这一步会差出一倍结果DPHY怎么都收敛不了。另外还想提醒一件事视频模式下面的DSI链路不是100%时间都在传像素。水平blank区域里链路要么休息、要么只发同步包所以实际配置的lane_rate通常会比理论值多留一些余量常见做法是留10%到30%。余量留太满信号质量容易崩余量不够带宽可能在极端画面下顶不上去表现为高帧率下滚屏或闪屏。2.3 video mode的burst和non-burst怎么选MIPI DSI视频模式下面还细分了non-burst with sync pulses、non-burst with sync events、以及burst mode。Burst模式的好处是水平blank期间可以把DSI链路切回低功耗状态休息到了有效显示区再提高速率把整行像素一次性发完带宽利用率高、屏体功耗也低。屏厂给的初始化序列和时序参数通常都是基于burst模式设计的。我见过有人图省事把BSP默认的burst改成了non-burst结果像素时钟明明够屏幕却开始闪烁。因为non-burst模式下在blank区还要持续发同步包DPHY的切换频率变高时序余量和burst完全不同。所以我建议除非你明确知道屏厂支持哪种模式并给出了对应参数否则不要动这个配置。3. 把面板驱动跑起来ST7701S初始化序列的调试细节3.1 panel驱动的注册路径在全志BSP里panel驱动通常实现为platform_driverprobe时获取reset引脚、电源和背光资源等到显示开启流程里再真正调用初始化命令发送。panel驱动要想正常probe前提是DSI控制器已经注册成功也就是说dts里节点的status要按依赖关系从底到上逐个打开。调试早期我习惯先确认三件事第一dmesg里有没有panel设备probe成功的log第二DSI控制器节点有没有在系统里初始化成功第三通过调试文件系统看panel的state是不是ready。这三件事都过了才开始往下查命令序列。3.2 ST7701S初始化序列的来龙去脉ST7701S的初始化序列看起来很像天书比如开头经常是FF 77 01 04 04 00这一串什么意思呢。在MIPI DSI协议里它是一条generic long write命令。ST7701S把它的寄存器分成多个bank你需要先发一个特定的页面切换序列把后续命令导向正确的寄存器页面然后才能配置分辨率、porch、gamma、电压这些参数。我把拿到手的几十条初始化序列分成四段来理解页面切换段用于锁定ST7701S的厂商寄存器页面显示参数段分辨率、porch、色彩格式、lane数面板特性段扫描方向、反色控制电压与gamma段VCOM、gamma曲线微调这样的分段方式在后续验证和改错时非常有用。我这次就遇到过屏能亮但整个画面偏绿的情况最后定位到是gamma段里某个电压寄存器写偏了一位。3.3 怎么验证初始化序列有没有真发出去一个非常有效的验证方法把整段初始化序列去掉只发0x11sleep out和0x29display on。如果屏幕能从睡眠状态醒来哪怕显示的是内部自检画面或白屏都说明命令通路是通的问题一定在具体寄存器配置上。如果这样都不亮那问题大概率发生在物理链路或者电源时序而不是寄存器内容。有条件的话用带MIPI协议解码功能的逻辑分析仪抓一下启动阶段的命令确认每条命令的payload和发送间隔是否和配置一致。没有协议分析仪时也可以通过BSP的调试开关把命令打印出来逐条比对虽然麻烦一点但也足够定位大都数问题。3.4 电源与同步时序里容易踩的坑屏的上电时序要求往往写在规格书里先是主电源再是IO电源然后reset引脚拉低一段最小时间再拉高最后才是发初始化命令。这个顺序错一点屏有时也能亮但工作极不稳定。我这次就遇到过一种情况reset引脚被BSP里的某个pinctrl配置影响电平始终拉不干净面板驱动读到的reset状态永远不对。查了快两个小时才发现是引脚复用冲突另外一个驱动模块把这个引脚申请走了。这类问题靠看代码很难发现因为你看到的dts配置是对的实际运行时的占用者却是别人。4. 设备树与时钟树逐级打开DSI通路4.1 dsi和panel节点的写法全志平台调MIPI通常至少要打开三处节点TCON、DSI控制器、panel。我这次用的dts节点简化长这样dsi { status okay; pinctrl-names default; pinctrl-0 dsi_pinctrl; panel0 { compatible st7701s,720x1280; reg 0; reset-gpios pio 4 20 GPIO_ACTIVE_LOW; power-supply reg_3v3; backlight backlight; }; };看起来简单但有几个容易漏的点。reset引脚有没有被别的驱动复用这个我在前面提过power-supply对应的regulator在跑起来之后实际输出电压对不对用万用表量一下比什么都靠谱backlight的PWM频率和极性如果不一致屏幕亮度会异常甚至有些屏会出现LC振荡噪声。4.2 时钟树配置的原则时钟树必须和第2节算出的lane_rate严格对齐。全志BSP里一般会把TCON和DSI相关的时钟速率写在assigned-clock-rates里。我的建议是先把pixel_clk和lane_rate确定再倒推PLL的配置并且尽量让PLL到最终输出之间是整除关系减少时钟抖动。我这次就把assigned-clock-rates从默认的值改成了跟模组规格匹配的206MHz附近的值。改完再验证的时候花屏现象明显少了。有人可能觉得这没啥但分辨率变了、刷新率变了这些assigned-clock-rates全部要跟着变这不是一个可以不管它的参数。4.3 冷启动和热复位的差异这次调试有个现象值得单独记录每次在系统运行中执行热复位屏幕都能正常出图但关机断电后再冷启动第一次进入Linux时黑屏的概率非常高。一开始我怀疑是屏体电源时序查了一大圈才发现是DSI控制器在冷启动时没有等D-PHY完全稳定就开始发初始化命令属于BSP里一个时序窗口问题。这种问题在标准DRM框架的RK平台上比较少见全志的老BSP里却不算罕见。排查思路是分别录制冷启动和热复位的完整串口log对比DSI控制器和DPHY的初始化时刻基本就能看出是谁先谁后。5. 黑屏复盘这次我走的完整排查链路5.1 先从日志缩小搜索范围我的排查顺序永远是先从内核日志下手panel驱动probe成功没有DSI控制器在发命令时有没有报TX timeout或者LANE错误TCON有没有抛data path异常日志都正常但屏幕不亮的时候我会去确认一个信息uboot阶段能不能把屏点亮。Linux下不亮、uboot下能亮基本说明屏体和面板参数没有大问题问题出在Linux侧的时钟或者电源配置反过来Linux能亮、uboot不亮那大概率要去查uboot的lcd参数和配置来源。这次在日志阶段有个关键词很显眼DSI控制器在发送初始化命令时连续报了几条host timeout。按我经验这多半是D-PHY根本没有进入高速模式命令发出去没人收。5.2 逻辑分析仪看LP到HS的切换接着我用了带协议分析能力的逻辑分析仪。MIPI DSI在进入高速模式之前D-PHY要经历固定的LP序列从LP-11切到LP-00再进入HS-Zero之后才真正开始传高速数据。如果这个切换时序不对接收端压根不会进入HS状态。我抓到的波形显示data lane上的bit流确实有但非常不稳定协议解码只能解出不到一半的数据包。当时的第一判断不是寄存器问题而是物理层信号质量问题。这就引出了后面那个核心问题deskew calibration。5.3 MIPI D-PHY deskew calibration这个坑关键词里被反复提到的MIPI DPHY deskew calibration这次还真是主角。它的作用是D-PHY为了保证多条数据lane和时钟lane在接收端对齐会在初始化阶段用一个训练窗口测量每一条lane之间的延迟差然后调整接收端的采样点。我遇到的现象是冷启动后前十行花屏半秒后自动恢复有时候干脆一直花屏。这种一会好一会坏的状态最迷惑人。我先把lane_rate从411.84Mbps降到350Mbps左右花屏立刻消失。这一步基本锁定了根因——信号裕量不足deskew校准没有一次成功。之后我把FPC排线重新拔插压平又回到410Mbps附近测试校准寄存器的状态恢复正常花屏消失。这里想说的经验是看到花屏、随机噪点不要一上来就怀疑屏的初始化参数先确认deskew校准有没有通过。有的BSP日志会打印一行有的压根不打印你需要主动把DPHY校准状态寄存器读出来看。5.4 低level的物理链路排查要排在前这次最花时间的其实是第一步我一开始在软件参数上反复试后来才发现排线接触问题。软件上改来改去毫无变化改成物理链路反而立竿见影。现在我的习惯是只要屏不亮又伴随花屏先花十五分钟把排线、连接器、金手指检查一遍确认物理链路干净之后再回头改软件。这个顺序倒过来往往就是几个小时的无用功。6. FPC排线调试现场最容易翻车的物理细节6.1 FPC插拔的标准步骤热词里有mipi口插入fpc的视频——别看这是一件小事现场插坏的真的不少。MIPI DSI接口用的FPC连接器常见两种掀盖式flip-lock和抽屉式pull-lock操作细节有区别但共同原则是一样的。正确步骤是断电操作确认FPC补强面和金手指朝向不要摸金手指插入时对齐连接器开口保证排线两端等高不要一边深一边浅压合锁扣时要均匀用力听到咔哒声后轻轻拉一下FPC确认已经锁紧。常见的错误带电插拔轻则接触不良重则烧掉屏端驱动IC甚至主机端的DPHY插线时没用镊子辅助排线歪斜进入导致金手指翻边锁扣没有完全压合机器振动几次之后屏就开始闪。6.2 排线本身的信号完整性问题MIPI差分对要求100Ω差分阻抗FPC越长、弯折越急损耗和lane之间的skew就越大。这次花屏问题里有一部分就是FPC一端金手指有一根微微翘起导致的。重新压平之后再没复发。对于超过15厘米的FPC最好在接收端用示波器看眼图确认幅度、上升沿和lane间的偏斜都在合理范围内。FPC走线附近要有足够的地参考差分对两侧有条件的话加地线包裹。这些板级细节在调软件调到头昏脑胀的时候往往想不到但恰恰是它决定了deskew calibration能不能通过。7. 几条花时间换来的调试习惯7.1 资料先行变更留痕这次调试之后我把自己的流程固化成了几条。第一屏厂资料四件套缺一不可第二每次改动只改一个变量调MIPI的时候变量太多同时改两处之后出了新问题根本分不清是谁的锅第三每一版修改都保留dts和驱动的diff记录配合串口log一并留档。很多难以复现的偶发问题最后都是靠这些历史diff才定位到的。7.2 有条件就搭FPGA验证台架另一个有价值的做法是用FPGA实现MIPI DSI发送端做一个裸屏测试台架。在改Linux驱动之前先用FPGA把屏点亮可以把屏体和排线的硬件问题与SoC配置的软件问题彻底解耦。FPGA里的MIPI控制器和全志BSP的实现方式肯定不一样但它能验证屏幕本身是不是好的也能帮助你观察信号质量。我个人体会是这次T527的MIPI DSI调试真正费时间的不是协议本身也不是驱动框架而是时钟计算的一环、deskew calibration的一环、FPC插接的一环。这三样看起来都很不起眼但任何一样出问题都足以让屏幕从可以点亮变成永远点不亮。希望这篇记录能让后面调屏的人少走一次弯路。