企业官网建设流程全解析

1. 从一条"屏幕不亮"的产线反馈说起

做全志T527的BSP调试，MIPI DSI这块几乎是绕不开的一道坎。我最近接手的一个项目，板子从打样回来到点亮屏幕，前后折腾了将近一周，中间踩的坑足够写一篇完整的复盘。问题的起点很朴素：产线反馈说新板子接上7寸MIPI屏，背光亮了但画面全黑，偶尔闪一下白屏就没了。这种"背光正常、无图像"的现象，在MIPI DSI调试里属于最典型的一类故障，它至少涉及供电、时钟、时序、lane映射、初始化序列五个环节，任何一个环节出问题都会表现成同一个症状。

全志T527这颗SoC在显示子系统上做了比较大的调整，它用的是Display Engine 2.0架构，MIPI DSI控制器支持4条数据lane，最高可以跑到每lane 1.5Gbps左右的速率，同时支持D-PHY的HS和LP两种模式。对于一块1024x600或者1280x800的屏来说，带宽是绰绰有余的，但正因为"够用"，很多人在配置时容易忽略时序参数的精确性，觉得差不多就行，结果就是点不亮或者点亮后花屏。

这篇文章我打算把T527上MIPI DSI从硬件确认到软件配置、从设备树编写到上电时序调试的完整链路讲清楚。适合正在做T527 BSP移植的驱动工程师、做方案定制的系统集成人员，以及刚接触MIPI DSI协议想找一个真实案例入手的嵌入式开发者。我不会只贴代码，而是把每一步"为什么这么配"讲透，因为MIPI DSI的坑，八成都是因为不理解参数背后的物理含义而埋下的。

2. 先搞清楚T527的DSI控制器到底管哪些事

2.1 DSI控制器、D-PHY和显示引擎的分工

很多人调MIPI DSI时把这三个东西混为一谈，导致出问题时不知道该查哪一层。在全志T527里，它们的分工其实很清晰。

Display Engine（DE）负责的是图层合成、缩放、色彩空间转换这些"像素级"的工作。它从内存里把framebuffer读出来，混合成一路RGB数据流，送到TCON（时序控制器）。DE不关心你接的是MIPI还是LVDS还是RGB，它只管输出符合时序的像素流。

TCON负责把DE送来的像素流按照屏幕的时序要求（HSYNC、VSYNC、DE、像素时钟）打包。T527的TCON支持多种输出接口，MIPI DSI是其中一种。

MIPI DSI控制器是TCON和D-PHY之间的桥梁。它把并行像素数据按照MIPI DSI协议打包成数据包（包括视频模式下的RGB数据包和命令模式下的DCS命令包），然后交给D-PHY。

D-PHY是物理层，负责把DSI控制器的数据转换成差分信号，通过lane发送出去。它管理HS（高速）和LP（低功耗）两种模式的切换，以及时钟lane的建立。

理解这个分层之后，排查问题就有了方向：如果背光亮但无图，先确认DE有没有正常输出（可以看DE的寄存器状态），再确认TCON时序对不对，最后才是DSI和PHY。我见过不少人一上来就改DSI参数，结果问题其实出在DE的时钟没使能。

2.2 视频模式和命令模式的选择逻辑

MIPI DSI有两种工作模式：视频模式（Video Mode）和命令模式（Command Mode）。这个选择直接决定了你的配置方式和屏的兼容性。

视频模式的特点是DSI控制器持续不断地向屏发送像素数据，屏不需要内置framebuffer，成本低。它的时序要求严格，必须匹配屏的HSYNC/VSYNC参数。大部分7寸以上的屏都用视频模式。

命令模式则是DSI控制器只在有更新时才发送数据，屏内部有GRAM（显存），控制器通过DCS命令读写GRAM。这种模式省电，但对屏的要求高（要有GRAM），且需要处理TE（Tearing Effect）信号来同步。

T527的DSI控制器两种模式都支持。选择依据很简单：看屏的规格书。如果屏支持视频模式，优先用视频模式，因为配置简单、兼容性好。如果屏只支持命令模式（比如一些低成本的MCU屏），那就必须用命令模式，并且要正确处理TE中断。

我这次用的7寸1024x600屏是视频模式的，所以后面的配置都围绕视频模式展开。但命令模式的关键差异我也会提到，方便用其他屏的人参考。

2.3 全志平台DSI配置的代码分布

在全志的BSP里，MIPI DSI相关的代码分布在几个地方，搞清楚这个对定位问题很重要。

设备树部分在arch/arm64/boot/dts/sunxi/下面，通常会有board.dts和board.dtsi两个文件。DSI的节点一般定义在disp.dtsi或者板级dtsi里，包括dsi0、dsi1两个控制器节点，以及panel子节点。

驱动代码在drivers/video/fbdev/sunxi/disp2/disp/下面，其中de/是显示引擎，tcon/是时序控制器，dsi/是DSI控制器驱动。全志的显示驱动是一个大的框架，DSI只是其中一部分。

关键的配置参数，比如lane数、速率、时序，都在设备树里。驱动会根据设备树的配置去初始化硬件。所以调试的第一步永远是确认设备树写对了。

3. 硬件层面的确认：别让板子的问题浪费你三天

3.1 供电和复位引脚的实测

在写任何代码之前，先用万用表把硬件确认一遍。这一步花十分钟，能省掉后面几天的瞎折腾。

MIPI屏通常需要三路供电：VDDI（IO电压，一般是1.8V或3.3V）、VDD（逻辑电压，1.2V左右）、AVDD（模拟电压，正负5V或正负5.5V）。有些屏还有VGH/VGL（栅极驱动电压）。这些电压的时序是有要求的，一般要求VDDI先上，然后VDD，最后AVDD，复位信号在供电稳定后拉低再拉高。

我这次遇到的问题之一就是AVDD的使能GPIO在设备树里配错了极性，导致AVDD一直没上电。屏的背光是由单独的背光IC驱动的，所以背光亮了，但屏的显示部分因为没供电完全不工作。用万用表量AVDD测试点，发现是0V，问题立刻定位。

复位引脚（RESET）也要确认。有些屏要求复位脉冲宽度至少10ms，有些要求1ms。如果复位时间不够，屏可能初始化失败。我一般会在驱动里把复位拉低延时20ms，拉高后再延时120ms，这个时间对绝大多数屏都够用。

3.2 MIPI lane的差分对和阻抗

MIPI DSI的物理连接是差分对，一条时钟lane加一到四条数据lane。T527的DSI0通常支持4条数据lane，DSI1支持4条。实际用几条取决于屏和带宽需求。

硬件上要确认两件事：差分对的极性有没有接反，以及走线阻抗是不是100欧姆。极性接反在有些平台上可以通过软件交换P/N来补救，但T527的D-PHY不支持自动极性翻转，接反了就只能改板或者飞线。我遇到过一块板子把lane0的P/N接反了，现象是初始化能过但图像全是雪花，查了两天才发现是硬件问题。

阻抗方面，MIPI的差分阻抗要求是100欧姆，单端50欧姆。如果走线阻抗不匹配，高速信号会有反射，表现为图像闪烁或者随机花屏。这个用示波器看眼图能看出来，但一般小团队没有这个条件，所以Layout阶段就要严格按规范走。

3.3 背光电路和PWM调光

背光虽然是独立电路，但它和DSI调试经常纠缠在一起。因为"背光亮了但无图"这个现象，很容易让人误以为DSI已经工作了，其实背光和DSI完全独立。

背光电路一般是一个升压IC加一个PWM调光输入。要确认的是：背光使能引脚（BL_EN）有没有拉高，PWM频率和占空比对不对。全志平台通常用PWM控制器输出调光信号，设备树里要配pwm-backlight节点，指定PWM通道和频率。频率一般设在1kHz到20kHz之间，太低会有可听噪声，太高可能超出背光IC的响应范围。

我习惯在调试DSI之前先把背光调好，确认背光能正常亮灭和调光，这样后面排查DSI问题时就能排除背光这个变量。

4. 设备树配置：每一个参数都有它的物理意义

4.1 DSI控制器节点的关键字段

T527的设备树里，DSI控制器节点的配置是整个调试的核心。我先把一个能工作的配置贴出来，然后逐字段解释。

&dsi0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; panel@0 { compatible = "panel-dsi"; reg = <0>; reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; power-supply = <&reg_avdd>; backlight = <&backlight>; port { panel_in: endpoint { remote-endpoint = <&dsi0_out>; }; }; }; }; &dsi0_out { remote-endpoint = <&panel_in>; >