这事得从一次调屏经历说起。有一年我拿一块MTK老平台开发板接HDMI显示现象特别刁钻开机logo正常进系统后偶尔闪一下十几分钟出现一次用户反馈说“像是被电了一下”。查了好几天最后定位到是MDP模块和DISP模块之间搬运数据时出现了FIFO溢出。那时候我就在想为什么MTK的显示子系统要把数据搬运和显示控制拆成两拨人管后来看到DDP架构出来我才真正理解这次演进解决的是什么问题。这篇文章就围绕MTK显示子系统的故事展开从老一代的MDPMobile Display Processor架构讲到现在的DDPDisplay Data Pipeline架构。适合做BSP驱动、显示中间件或者平台底层调试的工程师看也适合刚接触MTK平台、想在简历里多写点架构认知的朋友。我会把架构差异、关键模块、数据流原理、常见故障排查方式都拆开来讲尽量用实际调板子会遇到的问题带出知识点不整那些虚的。1. 从显示异常说起MDP架构为什么走到尽头1.1 早年MTK显示子系统的样子MDP架构时代MTK的显示子系统大致分成几块DISPLAY控制器负责时序和扫描类似传统LCD控制器、MDP处理器负责图层叠加、缩放、旋转、格式转换、以及DSI/HDMI/D-PHY这一类输出接口。这几个模块彼此独立各有各的寄存器基址各有各的驱动代码。上层应用做UI的时候GPU先渲染出图层再把图层交给MDP进行叠加合成。MDP完成后把最终画面写到内存bufferDISP再从这块内存读出来按时序送到屏幕显示。听起来没什么问题但这里有一个很明显的浪费同一帧画面在内存里被写了至少两次。第一次是GPU写入第二次是MDP写入合成结果第三次是DISP读取。每一次写入都是一次DRAM带宽消耗在分辨率上到1080P、刷新率上到60Hz以后再加上camera preview、video playback这类需要大量数据流的场景内存带宽马上吃紧。1.2 MDP时代绕不开的三类问题我调MT8173那段时间对这三点体会特别深。第一扩展新显示接口非常痛苦。HDMI是一个驱动DSI是一个驱动DP又是另外一套。看起来都是输出但接口驱动之间没有任何公共抽象软件上各写各的寄存器。想加一个eDP接口等于把整条链路重新做一遍。第二功耗优化基本靠猜。因为模块分散系统并不知道某一时刻哪些模块在工作只能靠驱动自己去判断。多起来的时候DISP、MDP、HDMI的时钟都在跑哪怕当前只是显示一张静态画面功耗也降不下来。第三调试问题靠经验不靠框架。有一次画面异常我手里只有一张示波器的截图要判断是MDP叠加出了问题还是DISP时序出了问题只能一点一点对着寄存器查。没有统一的数据流记录没有可追踪的管线状态排障全凭对代码的熟悉程度。,m,这些痛点直接推动了DDP架构的出现。DDP并不是简单地把模块改个名字而是把显示链路重构成一条有向的、可配置的、硬件级联的数据管线。2. MDP与DDP架构逐项拆解对比2.1 核心模块从“独立器件”到“数据管线”MDP架构里每个硬件模块更像是一个独立的处理器。有自己的FIFO、自己的中断、需要软件去调配什么时候开始搬数据、什么时候停止、什么时候等待。模块之间没有约定好的“接口协议”协同完全靠经验。DDP架构把屏幕上整条物理通路定义成一条DDP pipeline从图层输入经过叠加、色彩调整、gamma校正、抖动处理到最后输出到DSI或DP接口。每个硬件模块对应管线上的一个componentcomponent之间有固定的连接顺序硬件上采用ready/complete握手机制自动传递数据。拿一个典型的DDP数据路径举例OVL0 → RDMA0 → COLOR → CCORR → GAMMA → DITHER → DSI0OVL做图层叠加RDMA负责把叠加好的数据读取到FIFOCOLOR做色彩空间转换CCORR做色彩校正GAMMA做伽马调整DITHER做抖动处理最后由DSI接口发送到屏。每个component之间通过“握手”信号自动流转不需要主CPU全程参与。这样带来的好处是数据是一路流过去的不是每走一步都进一次DRAM。整个链路的实时性、确定性比MDP时代要好太多。2.2 软件栈从“各自为政”到“组件化抽象”对应的软件架构也跟着重构。MTK在Linux内核里把DDP相关驱动统一放到了DRMDirect Rendering Manager框架下路径通常在drivers/gpu/drm/mediatek/这里面有mtk_drm_ddp_comp.c、mtk_drm_crtc.c、mtk_drm_plane.c这一类文件。核心抽象是mtk_ddp_comp每个硬件component都通过这个结构体注册成DDP路径上的一个节点。举个例子设备树里会这样描述一个componentovl0: ovl14000000 { compatible mediatek,disp-ovl; reg 0 0x14000000 0 0x1000; interrupts GIC_SPI 225 IRQ_TYPE_LEVEL_LOW; clocks mmsys CLK_MM_DISP_OVL0; power-domains scpsys MT8173_POWER_DOMAIN_MM; };驱动初始化的时候drm_probe会挨个解析这些节点把它们添加到crtc的pipeline里。后续的图层提交、时钟管理、中断处理都是基于component的api来做的而不是像老驱动那样每个模块自己封装一套。2.3 数据流与关键路径MDP是搬运工DDP是流水线MDP时代每一次数据搬移都需要软件发起。MDP从内存读图层处理完写入内存DISP再从内存读。这个模式叫“store-and-forward”非常费DRAM带宽。DDP实现了真正意义上的“硬件流水线”。以扫描显示为例OVL直接读内存中的图层数据叠加完送给RDMARDMA不需要把结果写回DRAM直接以流式方式送到后面的色彩模块。数据停留在SRAM FIFO里不落地DRAM带宽占用可以省非常多。尤其是做视频播放时video plane和UI plane都走OVLOVL内部用两路layer输入途中无需CPU参与。对比MDP时代同样做视频叠加播放至少少了两次DRAM访问。2.4 DDP把功耗与性能的平衡做成了可控项DDP的另一个杀手锏是“每个component都可以独立控制时钟和电源”。系统可以根据当前任务动态决定打开哪几级component不需要的节点直接cut clock。比如显示一张静态桌面的时候色彩后处理链如果不需要可以把CCORR和GAMMA这两个模块的clock关掉只保留OVL、RDMA和DSI的时钟。这在MDP时代很难做到因为模块之间没有严格的上下级依赖关系随便关一个很可能影响别的模块。同时DDP对频率调节的支持更好。它可以通过硬件hrtimer或者总线监控感知帧率变化动态调整pll配置把显示链路的功耗压到比较低。这也是MTK敢在高端旗舰SoC上把显示链路继续往高刷方向推的原因。3. 谈到DDP这几个模块必须搞明白3.1 OVL图层叠加的关键功臣OVL在DDP里有点像拼接台。它接收多个输入图层支持不同格式RGBA8888、RGB565、NV12等、不同尺寸、不同透明度然后按Z-order把这些图层叠加成一张完整的framebuffer。实际用的时候最常配的是两个参数layer的base address和pitch。比如RGBA8888屏幕分辨率1080Ppitch一般就是1920乘以4等于7680字节。驱动里通过mtk_plane_atomic_update设置本质上就是把每个图层在DRAM里的地址和内存布局告诉OVL。OVL常见的问题是layer addr配置错位。比如底层UI plane地址写错一行屏幕底部会有一排花屏或者条纹。这种问题去看寄存器SCL的读地址和pitch值基本都能对上。3.2 RDMA与WDMA管线里的读/写搬运工RDMA全称Read DMA负责从DRAM读取已经合成好的画面数据或者从上游模块接收数据填到FIFO里再向下游模块输出。WDMA则是Write DMA负责把画面写到内存常用于截屏、录屏或者图像后处理输出。调试显示卡顿的时候RDMA的FIFO状态是重点观察对象。如果RDMA的读速度跟不上消费速度FIFO会underrun表现出来就是画面撕裂或者闪横条。我记得有一次排查1080P60显示闪烁发现RDMA的FIFO configured size是4096x128bit但MIPI DSI的吞吐率稍微高于RDMA从DRAM读取的能力FIFO持续被抽空。最后把DDR的频率档位提高一档完全解决。这里体现出来的核心原则就是整条DDP链路的瓶颈往往是带宽而不是单个模块。3.3 COLOR/CCORR/GAMMA/DITHER色彩后处理链DDP把色彩处理模块单独做成链路理论上你可以在链路里插多个色彩模块。COLOR做色彩空间转换比如YUV转RGBCCORR做色彩校正比如调节对比度、饱和度、RGB GainGAMMA做伽马校正适配不同面板的gamma曲线DITHER把高精度颜色打散到低精度位宽匹配8bit面板显示10bit内容。这块调试面板色彩偏色的时候会特别有用。之前一台设备色彩整体偏绿调GAMMA参数怎么调都偏。后来发现是CCORR里RGB Gain默认配的是10代码注释写的是“1.0”但实际寄存器精度并不是这个值配10被解释成了10倍增益。这就是典型的“看着是配置实际是惊喜”案例。提醒一句色彩参数这类东西除非你对寄存器语义非常清楚否则不要轻易动。调坏了不会报错只会在画面上慢慢折磨你。3.4 DSI与DP最后一道闸门DSI和DP是DDP管线出口直接决定信号能不能到达面板。MTK平台DSI支持Video Mode和Command Mode两种其中Command Mode主要用于AMOLED屏通过写寄存器刷新画面。DSI常见的坑是command mode下回读panel的TE信号时序。TE是tearing effect信号屏端在完成刷新后会拉高DSI要等TE才能发下一帧。如果回来晚了会掉帧回来早了会出现撕裂。DDP架构里TE检测通常和RDMA的帧同步放在一起管理不会像老平台那样写死等待时间。DP接口则更复杂一些涉及LTLink Training、AUX通道、DPCD寄存器读取这些。DDP里DP_TX作为pipeline的最后一个component接入链路训练失败时最常见的表现是外接显示器不亮或者闪烁。4. 实战调DDP一次线上问题的排查记录4.1 现象与初步判断有一台设备在低温环境下偶发闪屏屏幕显示完全正常但每隔几十秒会黑一下持续时间很短感觉像背光跳了一下。初步判断绕不开三个方向电源纹波、背光驱动、显示链路。先测量了背光电源纹波正常背光驱动IC控制信号也正常。接下来怀疑显示链路抗扰能力不足于是直接看DDP的状态。MTK在DRM框架下提供了一组debugfs接口一般在/sys/kernel/debug/dri/0/下面可以看到crtc的寄存器dump。做了一轮dump发现DDP管线里DSI模块报了一个ESD error flag。4.2 DDP dump怎么读拿mtk_drm_crtc来说dump_reg会打印出每个comp的状态寄存器。重点看几个标志位SOFstart of frame、EOFend of frame、FIFO underrun、FIFO overrun、以及DSI的error status。ESD error flag通常是DSI接收端状态异常但很多时候是上游数据流不稳导致的。DDP设计里如果上游component没有按规定帧时序送数下游的DSI会报错。所以看flag不能只看报错模块要从RDMA开始一层层往上排查。4.3 定位到RDMA的FIFO underrun进一步dump RDMA的寄存器发现FIFO underrun计数在持续累加。在低温环境下DDR刷新率会降低内存访问延迟上升RDMA从DRAM读数据的实际吞吐能力低于常规温度。那为什么平时不复现因为常温下DDR频率档位足够高RDMA可以快速把FIFO填满然后慢慢消耗。低温时内存retry变多读延迟加大RDMA在每帧起始阶段来不及填充FIFO导致DSI发出空白时钟画面瞬间被跳过。4.4 解决方式不是改RDMA而是调整DDR频率策略只要DDR频率适当提高低温下的latency就能被覆盖。但直接拉高DDR频率会增加功耗最后方案是调整DDR的动态调频算法让系统在识别到显示链路active时优先提高一个档位的DDR频率同时降低低温环境下的memory pll切换延迟。这类问题我在MDP时代很难定位到这么细。因为MDP和DISP是独立模块数据搬移哪里慢没有DDP这么清晰的链路状态可以追踪。DDP的优势就在这里状态可查、链路可断、数据路径一目了然。4.5 再补充两个经典问题排查经验图层顺序错乱屏幕显示的图层层级不对A盖住了B但逻辑上B应该在A上面。重点查OVL的layer enable和z-order配置常见原因是上层app创建plane时设置的zpos没有同步到OVL配置。带宽不足掉帧高分辨率高刷下UI滑动掉帧。重点看RDMA的FIFO配置和bus QoS设置。MTK平台通常可以把RDMA的QoS调高或者把OVL的smart fifo模式打开减少对内存带宽的依赖。5. 实操心得给正在做MTK显示适配的人5.1 别一上来就啃spec先理解数据路径很多新人拿到一个显示问题第一反应就是找对应模块的setting manual。但显示这块最重要的其实是整体数据流认知。你先得知道一张图从SurfaceFlinger出来经过哪些节点哪个节点负责叠加哪个节点负责输出才能在问题发生时快速判断“该看谁”。DDP架构里的核心难点不在于某个模块怎么配而在于一条pipeline里各个component之间的耦合关系。调OVL的时候要想到RDMA的带宽调RDMA的时候要想到DSI的吞吐。牵一发动全身这是显示链路和大数据链路的共性。5.2 遇到问题先dump别乱改配置我个人踩过最大的坑就是不看状态就猜配置。显示链路任何寄存器改动都不会马上崩通常会在几帧之后以某种怪异的画面呈现。与其浪费时间猜不如先做到两点第一把DDP全链路的状态寄存器dump一遍第二对比正常板子和异常板子的差异。MTK平台的debugfs接口非常有用/sys/kernel/debug/dri/0/state可以看到DRM的整体状态/sys/kernel/debug/dri/0/reg可以dump寄存器。平时调板的时候我是习惯先把这两份文件导出来再动手改代码。5.3 把工具链用起来显示性能问题光靠肉眼不靠谱。推荐几个实际用着顺手的路子内核开CONFIG_DRM_DEBUG配合ftrace看drm_atomic_commit的耗时。MTK自带的perf工具能看到各个显示模块的clock enable时长。系统层面看SurfaceFlinger的帧率统计dumpsys SurfaceFlinger --latency是必查项。在一台带DDP的MTK设备上一条比较完整的性能排查链路是从SurfaceFlinger的帧提交时间到DRM atomic_commit的完成时间再到RDMA读数据的时间最后到DSI发送的帧间隔。哪一段异常重点看哪一段的寄存器配合波形测量基本无往不利。5.4 架构演进的深层启示MDP到DDP表面上是模块重组实际上是显示子系统从“器件驱动思维”转向“数据流水线思维”。DDP让多个显示相关硬件真正做到co-design也给后续的高刷、低功耗、HDR、GPU合成优化这些功能铺好了底子。对我个人来说这种体验很像从“每台机器配一个搬运工”进化为“一条传送带自动运转”。MDP时代每个模块都等着软件去填空DDP时代只需要在流水线入口把图层摆好后面的步骤由硬件自己流转。最后分享一个小经验不管是用MDP还是DDP永远不要在显示链路上做“差不多就行”的调试。显示链路是最容易“看似成功但实际翻车”的模块。你今天跳过的一个小配置很可能变成屏幕上一道难以解释的横纹。调到每个寄存器都能说清楚为什么是这个值这块板子才算真正稳了。