一块新屏、一颗新触控芯片，第一次在新项目上电，串口只吐出几行 log，屏幕黑的，手指按上去毫无反应——这是高通平台上做 LCD 驱动和 TP 驱动 Porting 最标准的开局。我做这行这些年，接手过的点屏任务里，真正"一次点亮"的次数用一只手数得过来。大部分时间花在验证时序、对设备树、抓波形、复现触摸异常这几件事上。这篇就把 TP 与 LCD 两条链路的移植流程完整拆一遍，从软件栈分层讲到设备树字段，从初始化序列讲到故障定位，尽量把那些手册里写了但没人告诉你"为什么"的地方说明白。面向的是刚接手点屏任务、能看懂 dtsi 但不敢乱改的工程师，以及需要判断"问题到底出在屏还是出在触控"的调试人员。所有内容基于常见的通用实践整理，具体到某个平台代号我会做模糊处理，方法本身是通用的。

1. 开局就是黑屏：先把 TP 和 LCD 在这套平台上的分工与链路摸清楚

很多人接手点屏任务的第一反应是打开厂商给的初始化序列往 dtsi 里贴，贴完没亮就开始怀疑屏坏了。我见过太多这样的排查路径，最后发现是 bootloader 里的显示配置压根没同步，或者屏的复位脚和设备树里写的那根 GPIO 对不上。在动手改任何一个字节之前，先把整条链路走一遍，是省时间而不是浪费时间。

1.1 从 bootloader 到显示合成器，一次点屏要跨过几道门

在这类平台上，一块屏从通电到出现画面，至少经过三段彼此独立的软件栈，每一段都有自己的面板配置副本。

第一段是引导阶段的显示驱动。手机按下电源键之后，引导程序就已经在驱动显示屏了，用来显示充电图标、开机 logo、Fastboot 界面。这一段有自己独立的一套面板参数，和内核里的配置不是同一份文件。这是新手最容易栽的地方：内核里改得很完美，系统起来画面正常，但开机 logo 阶段一直黑屏或者只显示半屏，因为引导程序那份配置里分辨率、DSI 通道数、上电时序还是旧的。

第二段是内核态的 DRM 显示子系统。内核启动后接管屏幕，DSI 控制器、PHY、PLL 全部由这套框架管理，面板驱动作为 DRM panel 注册进去，负责下发初始化序列、管背光、处理休眠唤醒。现代平台的内核显示代码大多已经从主驱动目录里拆到独立的显示模块目录中，面板驱动模块编译成独立的 ko 或者编进内核，具体取决于项目的裁剪策略。

第三段是用户态的显示合成与 HAL 层。画面能不能显示出来，除了驱动要通，还要 HAL 能正确拿到面板的分辨率、刷新率、物理尺寸，合成器才会按正确尺寸出图。这一层出问题通常表现为画面能亮但比例错乱、状态栏被裁掉、旋转方向不对，而不是纯黑屏。

提示：三段栈的配置必须保持分辨率、DSI 通道数、面板时序三者一致。只改其中一段，症状一定是"某个阶段亮、某个阶段不亮"，这恰恰是最好定位的线索。

1.2 触摸看着独立，其实和屏绑在一根时序链上

触控芯片的驱动看起来是独立的 I2C 或 SPI 设备驱动，和显示没有任何代码耦合，但物理上它和屏共命运。原因有三个，每个都值得单独拎出来说。

其一是供电。不少项目的触控芯片 VDD 取自屏的 VDDI 或者面板的某一路电源轨，屏没上电，触控芯片就没供电，I2C 探测必然失败，日志里看到的是一串地址无应答。这时候如果只盯着触控驱动查，会一直查不出问题。

其二是复位顺序。触控芯片的 RESET 必须在它的供电稳定之后才能释放，而供电又依赖屏的上电完成。设备树里如果把触控的复位脚和屏的上电节点写在不同的初始化时机，就会出现概率性不识别——冷启动有时候认、有时候不认。

其三在功能层面。触控的坐标分辨率必须和显示的分辨率对上，否则手指点的地方和画面响应的位置差一截；屏幕旋转、折叠机型的双屏切换、AOD 息屏显示下的低功耗扫描，都需要触控和显示之间做状态同步。有些方案还会让触控的扫描周期跟着显示的 TE 信号走，用来降低触控到显示的响应延迟。

所以我在做移植的时候，习惯把屏和触控当成一个整体来调，先在屏上跑通上电时序，再在同一个上电窗口里把触控的复位塞进去，这样一次就能验证两条链路。

1.3 动手前必须向对接方要齐的四类资料

资料不齐就开工，等于闭着眼睛改代码。我列一下自己每次必问的四类东西，缺一样都会在后期以故障的形式还回来。

特别强调原理图这一项。规格书给的是芯片的能力，原理图给的是这块板子实际怎么接。我踩过最典型的一个坑：规格书写复位是低有效，但板子上加了一级反相，实际变成了高有效，结果驱动按低有效去拉复位，芯片永远处于复位状态，日志里一切正常，就是没反应。这种问题只有对着原理图看，或者拿示波器量电平才能发现。

2. 设备树是移植的主战场：DSI 面板节点的字段逐个过

内核里能不能点亮，八成取决于设备树写没写对。这一章把面板节点里那些看起来长得差不多、填错就直接黑屏的字段挨个拆开讲。

2.1 面板节点里哪些字段填错会直接黑屏

先看一个典型的 video 模式面板节点骨架，字段名在不同平台版本上略有差异，但逻辑是一致的。

&dsi_xxx_video { qcom,mdss-dsi-panel-name = "xxx video mode dsi panel"; qcom,mdss-dsi-panel-type = "dsi_video_mode"; qcom,mdss-dsi-panel-physical-type = "oled"; qcom,mdss-dsi-virtual-channel-id = <0>; qcom,mdss-dsi-stream = <0>; qcom,mdss-dsi-bpp = <24>; qcom,mdss-dsi-traffic-mode = "non_burst_sync_event"; qcom,mdss-dsi-lane-0-state; qcom,mdss-dsi-lane-1-state; qcom,mdss-dsi-lane-2-state; qcom,mdss-dsi-lane-3-state; qcom,mdss-dsi-lane-map = "lane_map_0123"; qcom,mdss-dsi-panel-width = <1080>; qcom,mdss-dsi-panel-height = <2400>; qcom,mdss-dsi-h-front-porch = <40>; qcom,mdss-dsi-h-back-porch = <40>; qcom,mdss-dsi-h-pulse-width = <10>; qcom,mdss-dsi-v-front-porch = <20>; qcom,mdss-dsi-v-back-porch = <12>; qcom,mdss-dsi-v-pulse-width = <4>; qcom,mdss-dsi-reset-sequence = <1 10>, <0 10>, <1 10>; };

这里每一个字段都能单独制造一次黑屏，我挑几个最容易出错的说明为什么。

通道状态与通道映射这两组字段必须和硬件走线一致。四个 lane 状态节点是"启用并指定通道顺序"的意思，删掉其中一个就等于告诉控制器用三通道驱动一个四通道的屏，后果是画面撕裂或者纯黑。通道映射则描述 PCB 上 lane 的物理排列，写反了会出现整屏花点、颜色错乱。做硬件改版的时候，这一栏一定要重新核对。

porch 参数决定了每一帧的消隐时间。前 porch 加后 porch 加脉冲宽度加有效像素等于行总时间，行总时间乘以行数再乘以刷新率，才是最终需要的像素时钟。填错最直接的后果是画面偏移、黑边、上下滚动，或者干脆因为时钟超出面板支持范围而不亮。我通常拿到规格书之后会手算一遍总时钟，和设备树里配置的时钟值对一下，对不上就说明某一个参数抄错了。

traffic-mode分 burst 和 non-burst，还分同步事件和同步脉冲。选错的表现是画面能亮但一直在抖或者出横条纹。这个字段没有"通用正确答案"，必须和面板规格书以及平台支持的模式对齐，抄同平台同类型面板的配置最省事。

bpp（色深）要和面板实际的接口位宽匹配。面板是 24 位，你配成 18 位，画面能出来但会有明显的色阶断层；反过来配高了则可能不亮。

2.2 上电时序表怎么和 reset-sequence 对齐

reset-sequence 是设备树里最不起眼、也最容易出事的一行。它的格式是若干组"电平 + 保持毫秒数"，按顺序执行。上面例子里的三组含义是：拉高保持 10ms，拉低保持 10ms，再拉高保持 10ms。

为什么是这个形状？因为面板的复位脚通常要求上电稳定之后先给一次有效复位，让芯片内部状态机归零，再释放进入正常工作。规格书里一般会画一张上电时序图，标出 VDDI、VDD、VSP/VSN 和 RESET 之间的先后关系以及各自的延时。移植时要把这张图翻译成两组配置：

• 电源轨的先后与间隔：通过panel-supply-entries引用的电源配置节点描述，每一路有最小/最大电压和上下电顺序；
• 复位脚的电平序列：就是 reset-sequence。

两边必须能对上，否则出现的是概率性黑屏——冷启动十次可能亮八次。这种问题在实验室很难复现，在产线上会直接变成不良率。

我的做法是拿示波器同时抓三路：主电源、IO 电源、复位脚，然后把实测波形和规格书的时序图叠在一起看。差个几毫秒肉眼看不出来，但差的是十几毫秒就一眼可见。实测下来最稳妥的方式是在复位的最后一段多留余量，把厂家给的 10ms 加到 15ms 甚至 20ms，多出来的时间对体验几乎没有影响，却能显著降低不良。

qcom,mdss-dsi-reset-sequence = <1 15>, <0 15>, <1 20>;

注意：加余量要加在"释放复位之后、下发初始化之前"这一段，不要把延时加在拉低复位之前，那样没有任何意义。

2.3 双面板、分屏 DSI 和 lane 映射的额外注意事项

折叠机型、双屏设备、以及部分大尺寸平板会把一块屏拆成左右两半，分别由两个 DSI 控制器驱动，这就是常见的分屏 DSI。这种配置下设备树会多出一整套字段，描述左右两半各自的起始坐标、宽度、以及哪个控制器负责哪一半。

移植的时候最容易出的三个问题：

第一是左右两半的初始化序列重复下发。有的方案要求两个控制器各自下发一份，有的要求只在主控制器上下发一份，规格书里会写明。下多了会出现半屏闪烁或者初始化不完整。

第二是刷新同步。两半画面不同步会出现中间一条撕裂线，尤其在快速滑动列表的时候特别明显。这个需要确认两个控制器的时序参数完全一致，并且启用了同步机制。

第三是 lane 数的分配。四通道的屏在分屏方案里可能被拆成每边两通道，那么每个控制器的 lane 状态配置就只应该启用两条。这个如果照抄四通道的配置，会直接黑屏。

3. 把屏点亮：初始化序列、背光和刷新率的落地细节

设备树对了，屏有可能会亮，但亮得对不对是另一回事。这一章讲三个决定"看起来正不正常"的部分。

3.1 厂商给的那串"魔法数组"怎么翻译成驱动里的 on-command

屏厂给的初始化序列通常是一张表格或者一坨十六进制，格式五花八门。要把它塞进 dtsi 的qcom,mdss-dsi-on-command，得先理解这个数组的编码规则。

每一行指令的前五个字节是控制头：类型、last 标志、虚拟通道、ACK 标志、等待时间。从第六个字节开始才是真正下发的数据。类型分几种，最常用的是短写（带一个参数）和长写（带一段数据）。长写的行会多一个长度字节，告诉控制器后面跟几个字节。

qcom,mdss-dsi-on-command = [ 39 01 00 00 00 00 04 B9 FF 83 94 05 01 00 00 78 00 01 11 05 01 00 00 14 00 01 29 ];

上面三行的含义大致是：先写一组厂商自定义的寄存器解锁，然后退出睡眠模式并等待约 120ms，最后打开显示并等待约 20ms。等待时间那一栏的单位是毫秒，这是最需要小心的地方——很多初始化失败的原因就是等待时间给短了。

这里有几个经验值值得记：退出睡眠模式之后至少留 120ms；打开显示之后至少留 20ms；进入睡眠模式之前要先关显示并留 20ms；断电之前留 120ms 确保睡眠命令生效。这些数字面板规格书里都有，但经常被抄漏。

还有一个坑：初始化序列里的某些寄存器写入必须在低功耗模式下进行，有些必须在高速模式下进行。设备树里对应有qcom,mdss-dsi-on-command-state这类字段来指定。写错了会出现"部分命令生效、部分不生效"的诡异现象，比如亮度可以调但画面不亮。

我一般会在驱动里加一行临时打印，把下发的每条命令和它执行后的返回状态都打出来，确认全部下发成功再往下走。这一步花十分钟，能省掉后面几小时的猜谜。

3.2 背光的三条常见通路与调光曲线的坑

屏亮了但背光不亮，等于没亮。背光控制在设备树里有几种类型可选，选错的表现是屏上有微弱图像但完全看不到，或者亮度无法调节。

调光曲线是另一个高频问题。硬件给的是线性的寄存器值，人眼感知是对数的，直接线性映射的结果是低亮度区间几乎看不出变化、高亮度区间一下子跳到刺眼。所以需要在驱动或者 HAL 层做一次映射。不同厂商对这条曲线的偏好不一样，有的要求在低亮度段用 DC 调光减少频闪，有的要求在某个阈值以下切到高频 PWM。

移植阶段我的建议是先不做任何曲线优化，用线性映射验证"亮度能从最暗调到最亮"这条通路是通的，等通路确认之后再叠加曲线。顺序搞反了，通路本身有问题却以为是曲线没调好，会白白绕远路。

亮度范围也要注意。设备树里有三组数值：面板支持的最小/最大亮度等级、系统亮度条的取值范围。这三者必须能对上，否则用户拖到最左端屏幕不灭、拖到最右端还没到最亮。

3.3 高刷切换、DSC 和多时序 buffer 的配置逻辑

现在的屏基本都支持多档刷新率，比如 60/90/120Hz。切刷新率的本质是同一块面板在不同的一组时序参数之间切换，所以设备树里会有多套时序配置，每套对应一档刷新率。

切档的实现方式有两种：一种是切换时序参数本身，另一种是面板内部有多组时序寄存器，通过下发命令切换。前者对 DSI 时钟要求高，后者更常见。移植时需要确认：

• 每一档刷新率的时序参数是否都写全了，包括 porch 和时钟；
• 切档命令的等待时间是否足够，切换瞬间如果时序还没稳定就出图，会看到短暂的花屏；
• 切档时的画面内容是否需要提前冻结，避免切换过程中撕裂。

DSC 压缩是另一个维度。分辨率高、带宽不够的时候必须开压缩，开了之后传输的数据量减小，但对面板的解压能力和配置一致性要求更高。设备树里要配置压缩比、切片高度、每片字节数等参数，这些数值必须和面板规格书完全一致，抄错一个就会花屏或者黑屏。

我踩过的一个坑是：开了 DSC 之后时序参数要按压缩后的数据量重新算，如果沿用未压缩的时钟配置，画面会在快速变化的时候出现局部块状失真。这个现象很容易被误判为屏本身的问题，实际是带宽配置不匹配。

4. 让触摸能用：从 probe 到报点，再到固件升级

屏亮了之后，触控是第二个战场。相比显示，触控的代码量小，但涉及的状态机更多，出问题的维度也更分散。

4.1 probe 阶段最容易漏的三个初始化动作

一个典型的触控设备树节点长这样：

&qupv3_se1_i2c { status = "okay"; touch@2c { compatible = "vendor,touch"; reg = <0x2c>; interrupt-parent = <&tlmm>; interrupts = <81 0x2002>; vdd-supply = <&L10A>; vendor,reset-gpio = <&tlmm 82 0x00>; vendor,irq-gpio = <&tlmm 81 0x2002>; pinctrl-names = "pmx_ts_active", "pmx_ts_suspend"; pinctrl-0 = <&ts_int_active &ts_reset_active>; pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; }; };

probe 阶段有三个动作最容易被漏掉，每一个都会导致"驱动加载成功但触摸没反应"。

第一个是电源轨的使能顺序。如果触控的 VDD 来自屏的某一路电源，必须在屏上电之后再使能，否则可能因为上电顺序不对导致内部状态机卡住。有的项目还要求 IO 电源先于主电源，规格书里会写。

第二个是复位的完整脉冲。只拉低不复位、或者复位保持时间不够，芯片不会重新初始化。我的习惯是拉低保持 10ms 以上，释放后再等 50ms 以上再尝试通信。

第三个是通信能力的自检。复位之后应该立刻读一次芯片 ID 或者版本号，确认 I2C/SPI 通路是通的。如果这一步失败，后面所有的初始化都是空谈。这一步做完再去做固件加载、参数配置、中断注册。顺序错了会出现驱动加载成功、但一有中断就报错的情况。

4.2 中断、坐标上报和方向适配

中断配置这里最核心的一点是触发方式要和硬件匹配。常见的是下降沿触发，配合IRQF_ONESHOT标志。如果硬件上加了上拉，中断脚空闲是高电平，按下时拉低，那么配成下降沿是对的。配成电平触发会出现中断风暴，CPU 占用飙升，日志被刷屏。

上报坐标走的是标准的输入子系统接口，核心几行大致是：

input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, tp->max_x, 0, 0); input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, tp->max_y, 0, 0); input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0); input_mt_init_slots(input_dev, TP_MAX_POINTS, INPUT_MT_DIRECT);

几个要点：坐标上报的最大值应该是面板的原始分辨率，而不是芯片的原始分辨率，两者往往不一样，中间需要做一次换算。多点触控要用 slot 机制，每个手指占一个 slot，抬起时把对应的 slot 置为无效，而不是简单发一个 up 事件。

方向适配是最容易出低级错误的地方。屏可以旋转，触控芯片贴装的方向不一定是正的，所以需要支持四个方向的坐标变换，以及 X/Y 交换。设备树里通常有对应字段，比如touchscreen-swapped-x-y、touchscreen-inverted-x这类标准属性。测试方法很简单：打开开发者选项里的指针位置，手指从左上角划到右下角，看显示的轨迹是否一致。不一致就逐个试四种组合，最多试四次一定能对。

提示：方向适配一定要在屏幕旋转的所有角度下都测一遍，包括横屏游戏、竖屏视频这些场景。很多项目只测了竖屏，横屏下坐标完全反了。

4.3 固件升级、自检与 LPWG 双击唤醒

固件升级是量产阶段绕不开的功能。驱动里一般通过请求固件文件，比对版本，不一致就下载，然后校验 CRC。这里有几个实战细节：

升级过程中必须关闭中断，否则手指一碰就打断升级流程；升级失败要有回滚机制，不能把芯片刷成砖；升级完成之后要重新走一遍初始化流程，不能假设芯片还在原来的状态。我见过最严重的一次事故是升级中途断电，芯片进入了不可恢复的状态，只能返修。

自检功能是产线用的，主要检查通道开路和短路。这个功能一般在工厂模式下调用，把结果写到指定节点，测试程序读取判断。移植阶段可以先不做，但接口要预留。

LPWG 也就是低功耗手势唤醒，是整个触控驱动里最考验细节的部分。工作流程是：系统进入休眠，触控芯片切到低功耗扫描模式，只有检测到特定手势才拉高中断把主控唤醒。这里的关键点有三处。

屏休眠和触控休眠的顺序要正确：一般是触控先进入低功耗模式，屏再关，顺序反了会出现误唤醒。中断唤醒能力要提前使能，enable_irq_wake必须在进入休眠之前调用。唤醒后的恢复流程要完整，包括重新配置芯片、恢复中断、上报一个有效事件。如果恢复不完整，表现为唤醒后第一次触摸没反应，第二次才正常。

5. 联调期的故障定位：黑屏、花屏、触摸漂移怎么一层层剥

前面讲的是"怎么让它跑起来"，这一章讲"跑不起来怎么办"。故障定位的核心思路是分层，每层都用一个明确的判据把问题范围砍掉一半。

5.1 黑屏的三层定位法：先看有没有电，再看有没有流，最后看有没有画

黑屏是最常见的症状，也是最容易误判的。我的排查顺序固定为三步。

第一步，确认供电。拿万用表量三路：主电源、IO 电源、背光电源。缺任何一路，后面都不用看了。这一步能解决大约三成的"黑屏"——很多是电源配置节点写错，或者 GPIO 控制的使能脚没拉起来。

第二步，确认有数据在发。看 DSI 总线上有没有波形，或者看控制器寄存器里有没有正在发送的状态。内核里通常有调试节点可以读控制器的状态寄存器，也能看到当前的时序配置。如果数据在发但屏不响应，问题在屏侧或者时序参数；如果压根没数据，问题在驱动或设备树匹配。

第三步，确认画面内容在出。前面两步都通了，屏幕还是黑的，可能是背光没开、可能是面板处于睡眠状态、也可能画面被合成到别的显示设备上去了。这一层要分别验证：往帧缓冲里写纯色，看是否变化；用命令手动打开背光，看是否有微光。三层走完，问题基本就锁定在某个具体环节。

这套方法的精髓是每一层都有可观测的物理量，不依赖猜。我见过有人一上来就怀疑屏坏，换了一块屏还是黑的，最后发现是设备树里复位脚编号抄错了一位。

5.2 花屏闪屏与 DSI 链路质量

花屏的表征有很多种：整屏雪花点、局部色块、横向条纹、间歇性闪白。不同的表征指向不同的原因，我整理了一张对照表。

链路质量还和走线强相关。差分线如果长度不匹配、阻抗不连续，在高速率下就会出现误码。这类问题在实验室常温下可能完全不显现，一到高温或者低温就冒出来。所以如果遇到"只在特定温度下花屏"，八成是链路裕量不足，而不是配置问题。

排查这类问题的一个实用手段是降速测试。把 DSI 速率临时降到一个较低的值，如果花屏消失，说明是速率相关的链路问题；如果依旧，说明和速率无关，回到配置层面查。

5.3 触摸不报点、跳点、鬼手的常见成因

触摸类故障我大致分成四类，每类的排查入口不同。

完全不报点。先看中断计数有没有增长。中断不增长说明芯片根本没检测到触摸或者中断没接上；中断有增长但不报点，说明数据上报的代码路径有问题，比如 slot 管理写错、上报时被提前 return。

坐标偏移。检查坐标分辨率配置是否和面板分辨率一致，检查是否有缩放逻辑。这类问题在只改了一部分配置的时候特别常见，比如换了屏但触控的分辨率参数没跟着改。

跳点。手指移动过程中坐标突然跳一段。原因可能是噪声、可能是上报频率跟不上、也可能是不同手指的 slot 混用了。可以临时关掉所有滤波和降噪逻辑看是否还跳，以此判断是算法问题还是数据本身的问题。

鬼手。没有任何触摸却持续报点。这个最麻烦，可能是硬件干扰，也可能是悬空通道没做屏蔽。常见的排查手段是逐个通道做自检，看哪个通道的电容值异常。

还有一类是"特定场景才出问题"：充电时触摸异常（电源干扰）、湿手触摸异常（水膜导致电容耦合）、贴厚膜后灵敏度下降（阈值需要重新标定）。这类问题往往不是移植阶段的 bug，而是参数标定的问题，需要原厂配合调。

5.4 休眠唤醒后的异常与 ESD 恢复

休眠唤醒是触控问题的高发区，症状包括唤醒后触摸失效、唤醒后第一次触摸延迟、无法唤醒、休眠后功耗异常偏高等。

针对"唤醒后触摸失效"，我一般检查三件事：中断是否重新使能了、芯片是否重新初始化了、有没有漏掉某个电源轨的恢复。这三个环节任何一个断掉都会失效，而且日志里可能完全看不到异常。

"休眠后功耗偏高"通常是芯片没有真正进入低功耗模式，或者 IO 口的上下拉配置不对导致漏电。可以通过测量休眠电流来定位，正常情况下休眠电流应该是个位数微安级别。

ESD 恢复是另一个独立话题。静电打到屏上或者触控上，芯片可能挂死或者进入异常状态。可靠的方案是：显示侧定期做状态寄存器读取，发现异常就主动重新初始化；触控侧通过中断长时间无响应或自检失败来触发复位。恢复流程要设计成"用户无感知"，也就是复位过程中不能出现画面闪烁或者触摸彻底断掉。

我在一个项目上遇到过 ESD 后屏幕变白的情况，恢复流程做了三秒才恢复，用户体验很差。后来改成两级恢复：先尝试轻量级的重新配置，失败再走完整复位，恢复时间缩短到几百毫秒。

6. 量产前的收尾：把"能亮"变成"敢出货"

实验室点亮只完成了工作的一小部分。真正让项目能过的是后面这一堆验证。

6.1 时序余量与温度、ESD 的组合压测

时序余量的验证方法是把关键延时参数按比例缩放，比如把复位延时、初始化等待时间、上电间隔分别缩短 10%、20%，看还能不能稳定点亮。能在缩短 20% 的情况下依然稳定，说明余量足够；只能在标称值下工作，说明配置本身就贴着边界，量产风险很高。

温度压测要覆盖高温、低温、以及温变过程。低温下屏的响应会变慢，如果初始化等待时间给的余量不够，会直接表现为低温黑屏。高温下电源纹波变大，可能出现花屏。温变过程最容易暴露的是材料热胀冷缩导致的接触不良。

ESD 测试至少要覆盖空气放电和接触放电两种方式，重点打在屏边框、触控区域、以及接口附近。每次放电之后检查：屏幕是否恢复正常、触控是否恢复正常、以及恢复需要多长时间。这三项都达标才算通过。

6.2 一份可执行的验证清单

下面这张表是我自己每次量产前都会跑一遍的清单，按模块组织，每项都写明判定标准。

清单本身不难，难的是每一项都认真跑完。我见过太多项目在实验室"看起来没问题"就出货，结果在用户手里暴露出低温不亮、休眠耗电这类问题，返修成本远高于测试成本。

最后分享一个我自己一直在用的小技巧：把上面这些验证项做成自动化脚本，通过调试接口批量执行，结果输出成表格。脚本本身写起来可能花一天时间，但后面每次改配置都能一键回归，比手工点几十次舒服太多。尤其是那种"改了一行设备树想知道有没有影响别的地方"的场景，自动化回归的价值最大。

再补一条个人经验。做 TP 和 LCD 移植，最容易犯的错误不是技术难度，而是假设——假设屏厂的初始化序列一定对、假设原理图上的 GPIO 编号一定没错、假设同平台其他项目的配置可以直接抄。这些假设里只要有一个不成立，后面就是几天的返工。每次接手新项目，我都会把"验证假设"这件事排在最前面，宁可多花半天对着原理图和规格书核对一遍，也不想在联调阶段被一个抄错的数字卡住两天。