1. 现象定位先把“黑屏有背光”拆成两个独立故障域做RK平台显示驱动最难缠的往往不是第一次点屏而是“休眠唤醒之后黑屏但有背光”这种半死不活的状态。rk3326搭配ST7701S这类MIPI DSI屏时这个问题尤其典型系统已经跑起来log也正常背光灯也亮着屏幕上就是什么都看不到。你写了几轮驱动甚至怀疑是屏坏了结果换个屏还是老样子这时候就需要冷静下来拆问题。先说结论背光亮意味着从系统到LED驱动、从PWM到背光电源这一路是完好的黑屏说明数据链路或者屏本身没有恢复工作状态。把这两个现象分开看问题范围立刻就小了一半。1.1 背光正常不等于显示链路正常很多工程师一看到“黑屏有背光”第一反应是去查backlight驱动。但实际上背光和显示数据通道几乎就是两条独立的链路背光由PWM、背光Boost芯片和LED灯条构成显示数据则要走SoC内部的DSI Controller、MIPI D-PHY差分线、屏端的TCON时序控制和面板驱动芯片。两者唯一的共同点是都会被“上电顺序”影响。拿日常例子来说黑屏有背光就像房间里的灯管能亮但电视机的信号源没有切进来。你换遥控器开关灯没用得去看机顶盒和视频线。对应到嵌入式平台就要看MIPI链路有没有建立、TCON有没有收到有效命令、面板寄存器是否还在工作状态。背光亮着至少说明系统休眠唤醒后负责背光的GPIO或PWM没有丢状态。这会带来一个隐蔽的风险因为背光正常很多人会忽略“唤醒后有没有完整重发panel初始化命令”这个动作反而去怀疑摄像头、触摸、电源管理等等无关模块。1.2 黑屏可能出问题的三个层级按照我自己的调试习惯黑屏问题一般分成三个故障域每个域排查方式完全不同。第一层是电源域。面板的AVDD模拟电压、IOVCC接口电压、VSP/VSN屏内正负电压这些供电rails在休眠时可能被regulator框架关掉了唤醒时如果恢复顺序不对或者根本没有恢复TCON芯片就不会正常工作。你量背光供电有电没用要量panel端AVDD、VSP、VSN这些点。第二层是DSI控制链路。从RK3326的DSI Controller到屏的TCON中间包括时钟lane、数据lane、PHY的PLL锁定状态、LP/HS模式切换。唤醒时常见的问题是PHY没有重新lock或者clk lane一直停在LP模式导致TCON收不到像素时钟自然黑屏。第三层是panel状态机。很多DSI屏有自己的内部电源管理状态比如Sleep Out、Display On这些DCS命令决定TCON是否真正把输入数据打到液晶面板上。休眠时进入Sleep In唤醒时如果只恢复了电源和链路却没有重新发Sleep Out和Display On就算MIPI波形正常屏也照样处于“待机不干活”的状态。2. 硬件时序与屏端恢复ST7701S这一类DSI屏的“标准动作”做驱动调试到最后拼的不是宏多不多而是对panel datasheet上的时序表够不够熟。RK3326平台上最常见的MIPI屏方案之一就是ST7701S几乎可以说rk3326休眠唤醒黑屏有背光十个里头有六七个是ST7701S唤醒时时序没补全。2.1 先读懂屏的上电和断电时序以ST7701S为例这类TCON内部的电源状态机比较严格上电顺序大方向是先供VCI和IOVCC再供VSP/VSN之后reset引脚要做一个完整的“高-低-高”脉冲然后等待晶振稳定再发Sleep Out。实际dts里如果你用的是panel-simple或者vendor驱动这些步骤通常分散在DTS节点、regulator的supply属性、以及驱动代码里。最容易踩的坑是休眠时把reset拉低了唤醒时却只是简单拉高没有做完整的低脉冲。TCON没有被正确复位内部的DCS寄存器可能就是乱的状态无论后面怎么发Sleep Out都起不来。我一般会在代码里强制按这个顺序走static int st7701s_resume(struct device *dev) { struct st7701s *ctx dev_get_drvdata(dev); // 1. 先恢复供电 regulator_enable(ctx-avdd); regulator_enable(ctx-iovcc); usleep_range(10000, 20000); // 2. reset拉低让TCON复位 gpiod_set_value_cansleep(ctx-reset_gpio, 0); usleep_range(10000, 20000); // 3. reset拉高TCON退出复位 gpiod_set_value_cansleep(ctx-reset_gpio, 1); usleep_range(10000, 20000); // 4. 送Sleep Out按手册等120ms mipi_dsi_dcs_set_sleep_out(ctx-dsi); msleep(120); // 5. 送Display On再等20ms mipi_dsi_dcs_set_display_on(ctx-dsi); msleep(20); return 0; }注意这里的GPIO极性只是示例不同屏的reset有效电平可能不一样务必以datasheet为准。另外msleep不能在原子上下文使用这点在resume回调里一般没问题但如果你放在spinlock保护区里就会直接panic。2.2 唤醒阶段需要的最小DSI命令集有些工程师图省事在唤醒时把整个初始化序列重新发一遍结果大部分情况也能亮但会带来两个隐患一是唤醒时间变长二是某些寄存器重复设置反而把TCON状态搞乱。最小恢复动作一般只需要两个命令0x11Sleep Out和0x29Display On。但前提是面板没有完全断电内部寄存器仍然保留初始值。如果系统休眠时把AVDD、IOVCC全部断掉了那唤醒后内部寄存器已经清空就必须把完整的init code重新下发否则颜色、gamma、分辨率都会不对。怎么判断是哪种情况一个很实用的办法是发读命令。ST7701S支持回读状态寄存器比如0x04读电源状态。正常工作时读到的是0x9C之类的值如果读到0x00或者读不到数据说明DSI链路还没建立或者TCON已经处于掉电状态。这里要注意很多DSI屏的读命令要通过mipi_dsi_dcs_read()发出去如果驱动没有实现transfer回调读操作会直接返回错误这也是一个排查方向。2.3 MIPI链路时钟和波形检查如果命令发了、时序也对了还是黑屏那就得怀疑MIPI物理层。网上关于“mipi信号波形”“mipi时钟波形”的讨论很多本质上都是在看D-PHY的两对差分线有没有正常翻转。最简单的方法是先算一遍lane rate够不够。DSI的时钟频率预算公式可以这么估算lane_rate (h_total * v_total * fps * bpp) / lanes例如一块1280x80060Hz的屏24bpp2 laneh_total2000v_total850那lane rate大约是2000 * 850 * 60 * 24 / 2 1,224,000,000 bps也就是1.224Gbps。这个速率在D-PHY Gen2以下问题不大但如果你的h_total和v_total余量没留够或者lane数只有1速率会被顶得很高PHY就容易锁不住时钟唤醒后自然黑屏。Rockchip平台在dts里通常有类似rockchip,lane-rate的节点需要根据屏参计算后填一个合理值不能照抄别人工程。有条件的话在唤醒瞬间用示波器抓MIPI差分波形。可以从三方面看一是看clk lane有没有从LP状态切到HS状态二是看data lane唤醒后在发什么命令三是看HS burst的幅度和过冲。如果clk lane一直是低电平那问题出在DSI PHY的使能顺序上如果发命令时有波形但屏幕无反应问题多半在TCON状态机。3. 内核驱动路径suspend/resume时RK平台到底做了什么单纯改panel驱动不一定能解决问题因为RK平台的休眠唤醒是DRM、DSI Controller、panel、backlight多个子系统协同的过程。顺序错了单独看哪一块都正常合在一起就是黑屏。3.1 DTS配置与panel节点检查清单先看panel节点本身。一个完整可用的RK DSI屏节点至少包含远程endpoint、reset引脚、背光引用、电源supply这几块下面是一个常见结构dsi0 { status okay; rockchip,lane-rate 500; panel0 { compatible startek,st7701s; reg 0; reset-gpios gpio1 RK_PB0 GPIO_ACTIVE_LOW; enable-gpios gpio1 RK_PA3 GPIO_ACTIVE_HIGH; pinctrl-names default; pinctrl-0 lcd_rst_l lcd_pwr_en; backlight backlight; power-supply vcc_lcd; port { mipi_in_panel: endpoint { remote-endpoint dsi_out_panel; }; }; }; ports { #address-cells 1; #size-cells 0; port1 { reg 1; dsi_out_panel: endpoint { remote-endpoint mipi_in_panel; }; }; }; };排查时重点看三处。第一reset-gpios和enable-gpios的极性是否和硬件一致。我发现很多“休眠唤醒黑屏”其实是reset引脚极性反了开机第一次能亮是因为bootloader或者硬件默认状态帮忙掩盖了休眠唤醒后驱动的严格时序反而暴露问题。第二power-supply对应的regulator在睡眠状态下有没有被强制关掉。可以通过regulator-state-mem、rockchip,suspend_voltage这类属性调整。调试早期最简单粗暴的办法是给panel供电加上regulator-always-on如果加完突发黑屏就消失了说明问题百分之百在电源恢复顺序。第三backlight节点不要放在panel的enable之前打开。背光和panel上电是有严格先后关系的ulan是panel先准备好再开背光否则屏幕会出现瞬间亮线甚至烧屏风险。这个顺序在dts里不一定能体现需要在驱动代码里控制。3.2 suspend/resume回调顺序为什么会丢RK平台典型的显示休眠路径大概是rockchip_drm_sys_suspend- 关闭CRTC -drm_panel_disable-drm_panel_unprepare- 关闭DSI PHY。唤醒路径反过来开DSI PHY -drm_panel_prepare-drm_panel_enable- 开CRTC。问题往往出在DSI Controller的runtime PM和panel回调之间。如果DSI Controller在drm_panel_prepare之前还没有完成runtime_resume那么panel里发Sleep Out命令时底层寄存器根本不可用命令发了个寂寞。这种情况的表现就是dmesg里一颗错误都没有因为调用链没报错但命令被丢弃了。定位这个问题有个笨办法在panel驱动的resume回调开头加printk同时追踪DSI Controller的runtime suspend/resume函数比对时序。另一种更快的方法是把DSI设备的runtime PM直接停掉强制它常开再试休眠唤醒。如果黑屏消失就说明是runtime PM恢复顺序不对。网上有人问到“如何将MIPI的时序导入bios的VBT”其实那是x86平台的思路RK平台没有VBT这种固件机制所有时序和电源顺序都在dts和内核驱动里控制尤其依赖drm_panel的prepare/enable回调顺序。理解了这一点就知道为什么RK平台显示驱动特别强调“回调顺序”而不是“配置表”。3.3 用自定义panel驱动控制完整恢复流程如果你的平台用的是全志、瑞芯微自带的panel-simple驱动它很多时候只是把GPIO、regulator、backlight依次操作了一遍不会替你重发初始化代码。对于ST7701S这类需要专用init code的屏最好自己写一个轻量panel驱动把休眠唤醒的完整恢复流程控制好。我踩过的一个坑是休眠阶段只调用drm_panel_disable里面的实现只关了背光没有发Sleep In也没有把reset拉低。结果面板内部还在“工作状态”唤醒后重新拉reset做低脉冲直接把TCON搞蒙了表现就是背光亮但屏幕永远黑。正确做法是在disable回调里把panel送到确定状态static int st7701s_disable(struct drm_panel *panel) { struct st7701s *ctx panel_to_st7701s(panel); backlight_disable(ctx-backlight); mipi_dsi_dcs_set_display_off(ctx-dsi); msleep(20); mipi_dsi_dcs_set_sleep_in(ctx-dsi); msleep(120); gpiod_set_value_cansleep(ctx-reset_gpio, 0); return 0; }这样每次唤醒都从同一个“已知状态”开始恢复黑屏几率会大幅下降。关键是disable和unprepare都要做干净不能只做一半。4. 排查实录从“黑屏有背光”到最终修复的三个现场案例理论说了一堆实际遇到问题时还是会一脸懵。这里分享三个亲手处理过的场景都属于rk3326 MIPI休眠唤醒黑屏有背光但原因完全不同。4.1 案例一dmesg干净唤醒后就是没图像有个项目用的RK3326配7寸ST7701S休眠唤醒后十次有三次黑屏有背光系统不死机不报错触摸也正常。查dmesg没有任何异常DRM的connect状态也正常功耗看起来都是在正常唤醒。后来我加打印在st7701s_enable回调里发现唤醒路径上这个函数有时候压根没被调用。再往上层查是drm_panel的prepare和enable回调在atomic commit时被跳过了。具体原因是CRTC的active标志没有恢复导致connector没有触发atomic_enable流程。当时的临时修复是在panel的resume回调里显式补发一次Display On命令相当于绕过DRM状态机给面板一个“强制叫醒”。根治办法则是升级内核里rockchip drm的suspend/resume补丁让CRTC状态和connector状态保持一致。这类问题的经验是不要只看panel驱动先确认DRM层的链路状态是否真的恢复了。4.2 案例二唤醒时频繁报DWC MIPI FIFO overflow另一个项目唤醒时日志里刷屏一样的DWC_MIPI_DSI_HOST_ERRFIFO溢出屏幕偶发能亮但画面抖动。一开始我以为是MIPI速率不够降了lane rate还是不行。后来发现是唤醒早期DSI Controller本身还在恢复中panel驱动就开始发DCS命令命令全堆在FIFO里然后溢出。解决方法是让panel驱动的resume回调等待DSI Controller的runtime_resume完成或者在panel enable之前加一个50ms到100ms的延时确保PHY已经稳定。另一个连带发现是dts里rockchip,lane-rate填得太高导致HS模式下链路预算不足。按前面给的公式重新计算后把lane rate从700降到500附近问题基本消失。4.3 案例三偶发黑屏屏幕像“没上电”一样还有一种情况是唤醒后背光亮但屏幕一丝变化都没有像是TCON完全没供电。用万用表量panel端AVDD发现电压不对立刻怀疑regulator的睡眠状态配置有问题。RK平台的regulator框架在dts里可以配置regulator-state-mem有些工程会把面板供电设为“睡眠时关闭”来省电。问题在于唤醒后regulator恢复的时序比panel驱动调用prepare要晚导致panel代码把reset和命令都发出去了电源还没到位。定位时我给panel加了一行cat /sys/kernel/debug/regulator/regulator_summary对比休眠前后vcc_lcd的状态发现它确实被切掉了。临时验证的话直接在panel节点加regulator-always-on如果黑屏从此消失就说明恢复时序没弄对。最终修复是在DTS的regulator节点里增加合适的regulator-state-mem配置把唤醒时的延迟控制好。4.4 常见问题速查表现象优先怀疑点快速定位手段有效处理唤醒后黑屏背光亮dmesg无错误panel没有收到Display On在panel enable回调加打印resume时补发0x11和0x29唤醒后黑屏日志有FIFO溢出DSI Controller还没就绪查看DWC MIPI错误日志调整DSI resume与panel resume顺序增加延时唤醒后偶发黑屏或灰屏regulator恢复时序不对查看regulator_summary重新配置regulator睡眠状态唤醒后花屏、颜色不对掉电后寄存器丢失读panel状态寄存器唤醒时重新发完整init code唤醒后闪屏、抖屏lane rate或clock裕量不足示波器抓MIPI HS波形重新计算lane rate并降低频率4.5 补充一个容易忽略的硬件点现在有些人会用FPGA做MIPI source来模拟屏幕或者用MIPI retimer做长线传输硬件链路里过多转接会造成时序变形。我遇到过一例客户加了转接板后休眠唤醒必黑屏把转接板去掉就正常最后发现是MIPI差分对在转接板处阻抗不连续HS模式下信号质量差正常工作时勉强能跑重新建链时却锁不住PHY。如果你排查软件时序很久没结果建议看看从主控到屏之间的MIPI走线有没有过孔太多、差分对等长有没有满足、串阻有没有贴错。RK平台DSI的规格上对走线长度和阻抗有明确要求mipi布线这类问题在量产阶段特别值得复查。最后还是那句老话黑屏有背光先拆域再抓波形最后改代码。不要一上来就怀疑驱动哪里做错了先把电源、时序、链路状态一个一个排除问题往往没有想象中那么神秘。
1. 现象定位先把“黑屏有背光”拆成两个独立故障域做RK平台显示驱动最难缠的往往不是第一次点屏而是“休眠唤醒之后黑屏但有背光”这种半死不活的状态。rk3326搭配ST7701S这类MIPI DSI屏时这个问题尤其典型系统已经跑起来log也正常背光灯也亮着屏幕上就是什么都看不到。你写了几轮驱动甚至怀疑是屏坏了结果换个屏还是老样子这时候就需要冷静下来拆问题。先说结论背光亮意味着从系统到LED驱动、从PWM到背光电源这一路是完好的黑屏说明数据链路或者屏本身没有恢复工作状态。把这两个现象分开看问题范围立刻就小了一半。1.1 背光正常不等于显示链路正常很多工程师一看到“黑屏有背光”第一反应是去查backlight驱动。但实际上背光和显示数据通道几乎就是两条独立的链路背光由PWM、背光Boost芯片和LED灯条构成显示数据则要走SoC内部的DSI Controller、MIPI D-PHY差分线、屏端的TCON时序控制和面板驱动芯片。两者唯一的共同点是都会被“上电顺序”影响。拿日常例子来说黑屏有背光就像房间里的灯管能亮但电视机的信号源没有切进来。你换遥控器开关灯没用得去看机顶盒和视频线。对应到嵌入式平台就要看MIPI链路有没有建立、TCON有没有收到有效命令、面板寄存器是否还在工作状态。背光亮着至少说明系统休眠唤醒后负责背光的GPIO或PWM没有丢状态。这会带来一个隐蔽的风险因为背光正常很多人会忽略“唤醒后有没有完整重发panel初始化命令”这个动作反而去怀疑摄像头、触摸、电源管理等等无关模块。1.2 黑屏可能出问题的三个层级按照我自己的调试习惯黑屏问题一般分成三个故障域每个域排查方式完全不同。第一层是电源域。面板的AVDD模拟电压、IOVCC接口电压、VSP/VSN屏内正负电压这些供电rails在休眠时可能被regulator框架关掉了唤醒时如果恢复顺序不对或者根本没有恢复TCON芯片就不会正常工作。你量背光供电有电没用要量panel端AVDD、VSP、VSN这些点。第二层是DSI控制链路。从RK3326的DSI Controller到屏的TCON中间包括时钟lane、数据lane、PHY的PLL锁定状态、LP/HS模式切换。唤醒时常见的问题是PHY没有重新lock或者clk lane一直停在LP模式导致TCON收不到像素时钟自然黑屏。第三层是panel状态机。很多DSI屏有自己的内部电源管理状态比如Sleep Out、Display On这些DCS命令决定TCON是否真正把输入数据打到液晶面板上。休眠时进入Sleep In唤醒时如果只恢复了电源和链路却没有重新发Sleep Out和Display On就算MIPI波形正常屏也照样处于“待机不干活”的状态。2. 硬件时序与屏端恢复ST7701S这一类DSI屏的“标准动作”做驱动调试到最后拼的不是宏多不多而是对panel datasheet上的时序表够不够熟。RK3326平台上最常见的MIPI屏方案之一就是ST7701S几乎可以说rk3326休眠唤醒黑屏有背光十个里头有六七个是ST7701S唤醒时时序没补全。2.1 先读懂屏的上电和断电时序以ST7701S为例这类TCON内部的电源状态机比较严格上电顺序大方向是先供VCI和IOVCC再供VSP/VSN之后reset引脚要做一个完整的“高-低-高”脉冲然后等待晶振稳定再发Sleep Out。实际dts里如果你用的是panel-simple或者vendor驱动这些步骤通常分散在DTS节点、regulator的supply属性、以及驱动代码里。最容易踩的坑是休眠时把reset拉低了唤醒时却只是简单拉高没有做完整的低脉冲。TCON没有被正确复位内部的DCS寄存器可能就是乱的状态无论后面怎么发Sleep Out都起不来。我一般会在代码里强制按这个顺序走static int st7701s_resume(struct device *dev) { struct st7701s *ctx dev_get_drvdata(dev); // 1. 先恢复供电 regulator_enable(ctx-avdd); regulator_enable(ctx-iovcc); usleep_range(10000, 20000); // 2. reset拉低让TCON复位 gpiod_set_value_cansleep(ctx-reset_gpio, 0); usleep_range(10000, 20000); // 3. reset拉高TCON退出复位 gpiod_set_value_cansleep(ctx-reset_gpio, 1); usleep_range(10000, 20000); // 4. 送Sleep Out按手册等120ms mipi_dsi_dcs_set_sleep_out(ctx-dsi); msleep(120); // 5. 送Display On再等20ms mipi_dsi_dcs_set_display_on(ctx-dsi); msleep(20); return 0; }注意这里的GPIO极性只是示例不同屏的reset有效电平可能不一样务必以datasheet为准。另外msleep不能在原子上下文使用这点在resume回调里一般没问题但如果你放在spinlock保护区里就会直接panic。2.2 唤醒阶段需要的最小DSI命令集有些工程师图省事在唤醒时把整个初始化序列重新发一遍结果大部分情况也能亮但会带来两个隐患一是唤醒时间变长二是某些寄存器重复设置反而把TCON状态搞乱。最小恢复动作一般只需要两个命令0x11Sleep Out和0x29Display On。但前提是面板没有完全断电内部寄存器仍然保留初始值。如果系统休眠时把AVDD、IOVCC全部断掉了那唤醒后内部寄存器已经清空就必须把完整的init code重新下发否则颜色、gamma、分辨率都会不对。怎么判断是哪种情况一个很实用的办法是发读命令。ST7701S支持回读状态寄存器比如0x04读电源状态。正常工作时读到的是0x9C之类的值如果读到0x00或者读不到数据说明DSI链路还没建立或者TCON已经处于掉电状态。这里要注意很多DSI屏的读命令要通过mipi_dsi_dcs_read()发出去如果驱动没有实现transfer回调读操作会直接返回错误这也是一个排查方向。2.3 MIPI链路时钟和波形检查如果命令发了、时序也对了还是黑屏那就得怀疑MIPI物理层。网上关于“mipi信号波形”“mipi时钟波形”的讨论很多本质上都是在看D-PHY的两对差分线有没有正常翻转。最简单的方法是先算一遍lane rate够不够。DSI的时钟频率预算公式可以这么估算lane_rate (h_total * v_total * fps * bpp) / lanes例如一块1280x80060Hz的屏24bpp2 laneh_total2000v_total850那lane rate大约是2000 * 850 * 60 * 24 / 2 1,224,000,000 bps也就是1.224Gbps。这个速率在D-PHY Gen2以下问题不大但如果你的h_total和v_total余量没留够或者lane数只有1速率会被顶得很高PHY就容易锁不住时钟唤醒后自然黑屏。Rockchip平台在dts里通常有类似rockchip,lane-rate的节点需要根据屏参计算后填一个合理值不能照抄别人工程。有条件的话在唤醒瞬间用示波器抓MIPI差分波形。可以从三方面看一是看clk lane有没有从LP状态切到HS状态二是看data lane唤醒后在发什么命令三是看HS burst的幅度和过冲。如果clk lane一直是低电平那问题出在DSI PHY的使能顺序上如果发命令时有波形但屏幕无反应问题多半在TCON状态机。3. 内核驱动路径suspend/resume时RK平台到底做了什么单纯改panel驱动不一定能解决问题因为RK平台的休眠唤醒是DRM、DSI Controller、panel、backlight多个子系统协同的过程。顺序错了单独看哪一块都正常合在一起就是黑屏。3.1 DTS配置与panel节点检查清单先看panel节点本身。一个完整可用的RK DSI屏节点至少包含远程endpoint、reset引脚、背光引用、电源supply这几块下面是一个常见结构dsi0 { status okay; rockchip,lane-rate 500; panel0 { compatible startek,st7701s; reg 0; reset-gpios gpio1 RK_PB0 GPIO_ACTIVE_LOW; enable-gpios gpio1 RK_PA3 GPIO_ACTIVE_HIGH; pinctrl-names default; pinctrl-0 lcd_rst_l lcd_pwr_en; backlight backlight; power-supply vcc_lcd; port { mipi_in_panel: endpoint { remote-endpoint dsi_out_panel; }; }; }; ports { #address-cells 1; #size-cells 0; port1 { reg 1; dsi_out_panel: endpoint { remote-endpoint mipi_in_panel; }; }; }; };排查时重点看三处。第一reset-gpios和enable-gpios的极性是否和硬件一致。我发现很多“休眠唤醒黑屏”其实是reset引脚极性反了开机第一次能亮是因为bootloader或者硬件默认状态帮忙掩盖了休眠唤醒后驱动的严格时序反而暴露问题。第二power-supply对应的regulator在睡眠状态下有没有被强制关掉。可以通过regulator-state-mem、rockchip,suspend_voltage这类属性调整。调试早期最简单粗暴的办法是给panel供电加上regulator-always-on如果加完突发黑屏就消失了说明问题百分之百在电源恢复顺序。第三backlight节点不要放在panel的enable之前打开。背光和panel上电是有严格先后关系的ulan是panel先准备好再开背光否则屏幕会出现瞬间亮线甚至烧屏风险。这个顺序在dts里不一定能体现需要在驱动代码里控制。3.2 suspend/resume回调顺序为什么会丢RK平台典型的显示休眠路径大概是rockchip_drm_sys_suspend- 关闭CRTC -drm_panel_disable-drm_panel_unprepare- 关闭DSI PHY。唤醒路径反过来开DSI PHY -drm_panel_prepare-drm_panel_enable- 开CRTC。问题往往出在DSI Controller的runtime PM和panel回调之间。如果DSI Controller在drm_panel_prepare之前还没有完成runtime_resume那么panel里发Sleep Out命令时底层寄存器根本不可用命令发了个寂寞。这种情况的表现就是dmesg里一颗错误都没有因为调用链没报错但命令被丢弃了。定位这个问题有个笨办法在panel驱动的resume回调开头加printk同时追踪DSI Controller的runtime suspend/resume函数比对时序。另一种更快的方法是把DSI设备的runtime PM直接停掉强制它常开再试休眠唤醒。如果黑屏消失就说明是runtime PM恢复顺序不对。网上有人问到“如何将MIPI的时序导入bios的VBT”其实那是x86平台的思路RK平台没有VBT这种固件机制所有时序和电源顺序都在dts和内核驱动里控制尤其依赖drm_panel的prepare/enable回调顺序。理解了这一点就知道为什么RK平台显示驱动特别强调“回调顺序”而不是“配置表”。3.3 用自定义panel驱动控制完整恢复流程如果你的平台用的是全志、瑞芯微自带的panel-simple驱动它很多时候只是把GPIO、regulator、backlight依次操作了一遍不会替你重发初始化代码。对于ST7701S这类需要专用init code的屏最好自己写一个轻量panel驱动把休眠唤醒的完整恢复流程控制好。我踩过的一个坑是休眠阶段只调用drm_panel_disable里面的实现只关了背光没有发Sleep In也没有把reset拉低。结果面板内部还在“工作状态”唤醒后重新拉reset做低脉冲直接把TCON搞蒙了表现就是背光亮但屏幕永远黑。正确做法是在disable回调里把panel送到确定状态static int st7701s_disable(struct drm_panel *panel) { struct st7701s *ctx panel_to_st7701s(panel); backlight_disable(ctx-backlight); mipi_dsi_dcs_set_display_off(ctx-dsi); msleep(20); mipi_dsi_dcs_set_sleep_in(ctx-dsi); msleep(120); gpiod_set_value_cansleep(ctx-reset_gpio, 0); return 0; }这样每次唤醒都从同一个“已知状态”开始恢复黑屏几率会大幅下降。关键是disable和unprepare都要做干净不能只做一半。4. 排查实录从“黑屏有背光”到最终修复的三个现场案例理论说了一堆实际遇到问题时还是会一脸懵。这里分享三个亲手处理过的场景都属于rk3326 MIPI休眠唤醒黑屏有背光但原因完全不同。4.1 案例一dmesg干净唤醒后就是没图像有个项目用的RK3326配7寸ST7701S休眠唤醒后十次有三次黑屏有背光系统不死机不报错触摸也正常。查dmesg没有任何异常DRM的connect状态也正常功耗看起来都是在正常唤醒。后来我加打印在st7701s_enable回调里发现唤醒路径上这个函数有时候压根没被调用。再往上层查是drm_panel的prepare和enable回调在atomic commit时被跳过了。具体原因是CRTC的active标志没有恢复导致connector没有触发atomic_enable流程。当时的临时修复是在panel的resume回调里显式补发一次Display On命令相当于绕过DRM状态机给面板一个“强制叫醒”。根治办法则是升级内核里rockchip drm的suspend/resume补丁让CRTC状态和connector状态保持一致。这类问题的经验是不要只看panel驱动先确认DRM层的链路状态是否真的恢复了。4.2 案例二唤醒时频繁报DWC MIPI FIFO overflow另一个项目唤醒时日志里刷屏一样的DWC_MIPI_DSI_HOST_ERRFIFO溢出屏幕偶发能亮但画面抖动。一开始我以为是MIPI速率不够降了lane rate还是不行。后来发现是唤醒早期DSI Controller本身还在恢复中panel驱动就开始发DCS命令命令全堆在FIFO里然后溢出。解决方法是让panel驱动的resume回调等待DSI Controller的runtime_resume完成或者在panel enable之前加一个50ms到100ms的延时确保PHY已经稳定。另一个连带发现是dts里rockchip,lane-rate填得太高导致HS模式下链路预算不足。按前面给的公式重新计算后把lane rate从700降到500附近问题基本消失。4.3 案例三偶发黑屏屏幕像“没上电”一样还有一种情况是唤醒后背光亮但屏幕一丝变化都没有像是TCON完全没供电。用万用表量panel端AVDD发现电压不对立刻怀疑regulator的睡眠状态配置有问题。RK平台的regulator框架在dts里可以配置regulator-state-mem有些工程会把面板供电设为“睡眠时关闭”来省电。问题在于唤醒后regulator恢复的时序比panel驱动调用prepare要晚导致panel代码把reset和命令都发出去了电源还没到位。定位时我给panel加了一行cat /sys/kernel/debug/regulator/regulator_summary对比休眠前后vcc_lcd的状态发现它确实被切掉了。临时验证的话直接在panel节点加regulator-always-on如果黑屏从此消失就说明恢复时序没弄对。最终修复是在DTS的regulator节点里增加合适的regulator-state-mem配置把唤醒时的延迟控制好。4.4 常见问题速查表现象优先怀疑点快速定位手段有效处理唤醒后黑屏背光亮dmesg无错误panel没有收到Display On在panel enable回调加打印resume时补发0x11和0x29唤醒后黑屏日志有FIFO溢出DSI Controller还没就绪查看DWC MIPI错误日志调整DSI resume与panel resume顺序增加延时唤醒后偶发黑屏或灰屏regulator恢复时序不对查看regulator_summary重新配置regulator睡眠状态唤醒后花屏、颜色不对掉电后寄存器丢失读panel状态寄存器唤醒时重新发完整init code唤醒后闪屏、抖屏lane rate或clock裕量不足示波器抓MIPI HS波形重新计算lane rate并降低频率4.5 补充一个容易忽略的硬件点现在有些人会用FPGA做MIPI source来模拟屏幕或者用MIPI retimer做长线传输硬件链路里过多转接会造成时序变形。我遇到过一例客户加了转接板后休眠唤醒必黑屏把转接板去掉就正常最后发现是MIPI差分对在转接板处阻抗不连续HS模式下信号质量差正常工作时勉强能跑重新建链时却锁不住PHY。如果你排查软件时序很久没结果建议看看从主控到屏之间的MIPI走线有没有过孔太多、差分对等长有没有满足、串阻有没有贴错。RK平台DSI的规格上对走线长度和阻抗有明确要求mipi布线这类问题在量产阶段特别值得复查。最后还是那句老话黑屏有背光先拆域再抓波形最后改代码。不要一上来就怀疑驱动哪里做错了先把电源、时序、链路状态一个一个排除问题往往没有想象中那么神秘。
