企业官网建设流程全解析

MTK平台上做显示驱动调试的兄弟，对drm_crtc.c应该不陌生。这一章我们继续沿着MTK DRM框架往下走，聚焦到KMS（Kernel Mode Setting）里最核心、也最容易让人绕晕的一个文件——drm_crtc.c。前几篇已经把DRM整体框架、connector、encoder这些链路梳理过了，到了CRTC这一层，意味着真正进入显示管线的核心输出通道。

简单说，CRTC是KMS里管“时机”和“数据流走向”的角色。它不负责具体像素内容，但负责决定像素什么时候从内存取、按什么时序送到encoder、多块图层怎么在硬件上叠加混洗后输出。这在MTK平台上，对应的是DISPSYS子系统里的OVL、RDMA、DP_INT、COLOR、AAL、GAMMA这些硬件模块的协同调度。如果你调过花屏、闪屏、帧率不稳、图层叠加异常这类问题，十有八九最终都会追溯到CRTC这条链路。

这篇文章适合手里有MTK平台源码、正在啃DRM驱动，或者被显示时序和vblank问题折磨过的内核驱动工程师。我会沿着drivers/gpu/drm/mediatek/mtk_drm_crtc.c这个文件的核心逻辑展开，从数据结构、初始化流程、atomic操作到vblank中断和上下电流程，逐段拆解。

1. CRTC在MTK DRM里的角色定位与代码结构

1.1 CRTC是什么，为什么它能串起显示链路

从KMS的抽象角度看，CRTC（Cathode Ray Tube Controller）这个名字比较古老，但职责一直没变：它代表一个显示扫描输出控制器。在PC时代CRTC负责生成行场同步信号、控制电子枪扫描；到了现代SoC上，CRTC演变成了一个虚拟的显示输出流水线控制器，承担三件事情：

• 从framebuffer读取像素数据（对应MTK的OVL/RDMA）
• 对像素做色彩处理（对应MTK的COLOR/AAL/GAMMA）
• 把处理后的数据按时序发送给encoder（对应MTK的DP_INT，即显示端口接口）

在MTK平台，每个显示接口（DSI、DP、HDMI）都会对应一个mtk_drm_crtc实例。以常见的MT6779/MT8192等平台为例，多路显示并行工作，每个crtc独立跑自己的流水线，互不干扰。正是因为CRTC是整条输出链路的调度中心，所以你在drm_crtc.c里会看到大量与时钟管理、irq管理、电源域控制相关的代码。

1.2 mtk_drm_crtc核心数据结构拆解

打开mtk_drm_crtc.c，第一眼看到的是mtk_drm_crtc这个结构体，它是整个CRTC驱动的主控结构：

struct mtk_drm_crtc { struct drm_crtc base; struct device *dev; struct mtk_disp_ovl *ovl; struct mtk_disp_rdma *rdma; struct mtk_disp_color *color; struct mtk_disp_aal *aal; struct mtk_disp_gamma *gamma; struct mtk_drm_ddp_comp *ddp_comp[MTK_DDP_COMPONENT_COUNT]; // ... struct drm_pending_vblank_event *event; wait_queue_head_t wq; u32 pending_planes; bool layer_config_crtc; };

这个结构体里的字段需要分几类理解：

第一类是硬件组件指针，包括ovl、rdma、color、aal、gamma等。它们对应MTK DISPSYS里具体硬件模块的驱动实例接口。CRTC就是通过这些指针来调度不同硬件模块的。

第二类是DDP（Display Data Pipeline）组件数组，ddp_comp。这个数组保存了当前CRTC所关联的所有数据通路组件。MTK平台在dts里通过compatible和mediatek,dpi等属性描述每个CRTC关联哪些硬件模块，driver初始化时按dts配置填充这个数组。

第三类是状态管理字段，包括pending_planes、layer_config_crtc、event等。这些字段用于atomic操作过程中跟踪状态，保证一帧画面的配置在适当的时机生效。

我在实际调试过程中发现，理解ddp_comp数组的排列顺序特别重要，因为它决定了硬件数据流的方向。MTK各平台显示数据流一般是：

OVL -> RDMA -> COLOR -> AAL -> GAMMA -> DPI_INT -> encoder

也就是说，CRTC操作时按照ddp_comp数组顺序依次配置每个硬件模块，形成一条完整的数据通路。如果你在dts里配错了组件顺序，出现的现象是画面内容异常但FrameBuffer配置完全正确——这类问题在早期bring-up时最让人头疼。

1.3 一次典型的CRTC驱动初始化流程

在投递到atomic配置之前，CRTC首先要完成初始化和注册。mtk_drm_crtc_init是入口函数：

int mtk_drm_crtc_init(struct drm_device *drm_dev, struct mtk_drm_crtc *mtk_crtc, struct mtk_drm_private *priv) { struct device *dev = priv->dev; struct device_node *node = dev->of_node; struct mtk_ddp_comp *ddp_comp; int comp_id, ret; // 获取crtc关联的ddp管线的comp // 初始化base crtc，并注册helper funcs ret = drm_crtc_init_with_planes(drm_dev, &mtk_crtc->base, primary_plane, cursor_plane, &mtk_crtc_funcs, NULL); // 初始化vblank相关 drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc); // 初始化等待队列 init_waitqueue_head(&mtk_crtc->wq); }

整个初始化流程里有几个关键点值得关注：

一是drm_crtc_init_with_planes的作用。它把primary plane和cursor plane绑定到CRTC上。在MTK平台上，主平面通常对应mtk_plane.c里的实现，通过这个平面传入的framebuffer就是用户程序调用DUMB_CREATE和FB_CREATE创建的那个buffer。绑定之后，CRTC才知道“我从哪里取数据”。

二是vblank初始化。drm_vblank_init做的事是为每个crtc分配vblank计数器以及对应的中断处理上下文。MTK平台在irq处理中会上报vblank事件，这里如果不初始化，后台上报的时候会直接crash。

三是等待队列的初始化。wq主要用于完成等待异步操作，比如等待dsp流水线完成某个任务。MTK的流水线有些操作是异步的，配置完成后需要等待硬件完成信号，wq配合pending_planes字段在等待同步中起到很关键的作用。

2. KMS Atomic操作在MTK CRTC中的落地实现

2.1 atomic_begin与atomic_flush：一帧画面的开始与结束

现代DRM驱动基本都是围绕原子化操作（Atomic Modeset）来设计。CRTC层面的核心回调函数是atomic_begin和atomic_flush，它们是一帧画面提交流程的起点和终点。

MTK的实现如下：

static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); if (crtc->state->event) { mtk_crtc->event = crtc->state->event; crtc->state->event = NULL; } } static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); // 等待可能存在的pending任务 // 配置每个ddp comp的buffer地址 // 触发vdpp }

atomic_begin阶段的主要工作是把用户层提交的vblank事件暂存到mtk_crtc->event。为什么要暂存而不是直接用crtc->state->event？这是因为在atomic操作流程里，状态对象会被提交和清理，event指针如果不拿走，后续提交完成前就可能被清掉，导致用户层收不到vblank事件。

atomic_flush阶段才是真正干活的函数。MTK在这里需要完成几件事：

• 遍历所有ddp_comp，为每个硬件组件配置数据源buffer地址。这就是把framebuffer的gem对象内部的地址寄存器告诉OVL/RDMA。
• 调用mtk_ddp_comp_layer_config，这个是关键函数。它根据plane的配置（格式、偏移、裁剪、透明度）去设置OVL各图层的寄存器。
• 最后，对于有mutex（互斥锁）的平台（如MT8192），还需要调用mtk_disp_mutex_acquire/mutex_add_comp来确保整条数据管线同步使能。

这块最容易出问题的是layer_config的顺序。多个plane叠加时，OVL的layer index与平面优先级必须匹配。index小的在底层，index大的在上面。如果用户层用zorder属性指定了图层顺序，而CRTC没有正确解析，就会出现画面遮挡关系错乱。

2.2 atomic_enable与atomic_disable：硬件上下电时序的控制

如果说atomic_begin/flush关注的是每帧数据流，那么atomic_enable和atomic_disable则是关注整体显示开关的时序。这两个回调函数是整条显示链路的电源和时钟控制入口。

MTK的实现大致如下：

static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); // 打开crtc的电源域/clk // 初始化ddp流水线 mtk_ddp_comp_enable(comp); // 启动mmsys时钟 // 解除data path reset // 使能各个comp // 开始crtc的输出 mtk_drm_crtc_start(mtk_crtc); }

这个函数是解决了“屏幕亮起来”的关键路径。它里面的调用顺序我非常建议各位对照硬件datasheet读一遍，因为在MTK的多个平台上，这个顺序哪怕调换一步，都可能带来极其难查的怪问题。

比如，必须先使能clock再操作寄存器。这不是废话吗？但实际操作中，你无法预料上层AHB总线时钟是不是在suspend的时候被关闭了。如果clk没开就操作了CRTC相关寄存器，系统会直接在总线上挂死或者读到全0xFF。这类问题的排查在正常运行时很难复现，但在系统低功耗后唤醒时会频繁出现。

再比如，每个DDP comp的复位时序也要准确。MTK很多显示模块带soft reset寄存器，在片选后释放reset前需要等待至少一个clk cycle。代码里使用的是readl_poll_timeout，循环等待状态寄存器到位，这个不能省略。

atomic_disable则是相反的流程：

static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); // 停止crtc mtk_drm_crtc_stop(mtk_crtc); // 关闭ddp流水线 mtk_ddp_comp_disable(comp); // 等待硬件进入idle // 关clk }

注意这里mtk_drm_crtc_stop并不是直接把寄存器清零完事。MTK的做法是先停止VDPS（Video Data Path Switch），然后把各个comp置于idle状态，接着等待中断确认所有pending transaction已经完成，再关闭clock。如果你的驱动版本直接硬关clk，很大概率在下一次enable时出现模块状态不同步，表现出来就是花屏或帧数只有原来的一半。

2.3 在atomic_check中做的合理性检查

除了控制硬件的几个回调，CRTC还有一个纯软件层面的检查函数——atomic_check。这个函数不做任何硬件操作，它只做参数校验和资源可行性评估，说白了就是判断“用户这次提交的显示配置，我硬件到底能不能干”。

MTK实现里重点检查几项：

• mode是否在panel/digitizer支持的范围内，这通常通过drm_mode_validate等在encoder那边已经做了一部分，CRTC这边会检查timing参数是否和clock能匹配上。
• plane格式组合是否可行。MTK平台OVL各layer支持的格式不完全一样，比如底层layer通常要求支持带alpha的BGRA8888；如果用户层提交了一个底层layer带ARGB2101010格式，但硬件不支持，model配置就没戏，需要在这里拦截。
• 总带宽估算。多路显示、高分辨率大刷新率时，内存带宽可能不够，需要在check里做一个粗算，提前把不可能完成的配置拒掉，避免运行后掉帧。

这部分我强调一下：atomic_check不是做做样子，它是DRM atomic操作的核心优势之一——失败预判。一个写好的check函数，能帮你屏蔽掉90%以上的非法提交，让系统在任何状态下都能保持显示可用性。

3. vblank中断管理与帧完成事件上报

3.1 vblank中断在CRTC代码里的实现机制

CRTC驱动的另一件大事是vblank中断管理。在MTK平台上，vblank信号来自显示接口模块（DSI/DP/HDMI），由MIPI_TX或者HDMI的TX控制器产生，之后触发到GIC。在mtk_drm_crtc.c中，通过mtk_drm_crtc_irq这个函数来处理：

static void mtk_drm_crtc_irq(struct drm_crtc *crtc) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0]; u32 irq_status; // 读取中断状态寄存器，确认vblank状态 irq_status = mtk_ddp_comp_read_frame_done(comp); if (irq_status) { // 上报一个vblank事件 drm_crtc_handle_vblank(crtc); // 如果有损耗事件，发回用户空间 if (mtk_crtc->event) { drm_crtc_send_vblank_event(crtc, mtk_crtc->event); mtk_crtc->event = NULL; } } }

这里的关键点是drm_crtc_handle_vblank。它做两件事：通知DRM core把vblank计数器加一；唤醒所有在这个vblank上等待的进程。上层用户空间通过DRM_IOCTL_WAIT_VBLANK等命令，实际上就是在等这个计数器的变化。

mtk_crtc->event的发送也很重要，它对应的是用户层的page flip事件。应用程序在ModeSet后请求一个PageFlip，驱动在内核态配置新的buffer地址，然后等vblank来临时把事件发回用户空间。这样用户空间就知道“这一帧已经展示了”，可以安全提交下一帧了。如果这里event没发或者发太早，应用层动画就会出现一顿一顿的情况。

3.2 vblank中断丢失时怎么查

vblank是显示调试中最容易出问题的地方。如果你做gpu显示的时候发现帧率只有预期一半，首先怀疑方向就是vblank中断丢失。

MTK平台vblank中断丢失，我的排查思路是这样的：

第一步，确认中断有没有产生。在mtk_drm_crtc_irq入口加个count打印，看看一秒钟能进来多少次。如果进来次数和刷新率一致，说明中断源没问题，问题在中断处理内部的逻辑。

第二步，确认中断状态寄存器读出来是不是有帧完成标志。这里有个极易踩的坑：MTK的frame done标志位是write-1-clear的，但不同平台status寄存器的比特位含义不同。在MT8192上是bit0表示ODD帧，bit1表示EVEN帧，而MT8183上可能只有bit0。如果你错误地在同一个寄存器上清除了另一个模块的中断标志，可能导致其他模块的中断永远不再产生。

第三步，检查vblank enable/disable计数。drm_vblank_on/off是对称调用的，如果中途有个调用栈把vblank disable了，中断会上报但不处理。这时crtc->state->vblank_enabled为false，你可以直接检查这个flags来判断状态。

我在实际项目中还遇到过一种情况，就是bl和power_save逻辑把显示时钟关了，但vblank中断没有关。硬件侧的vblank中断仍能触发，但软件侧因为pixel clock没了，frame done中断实际已经无法产生。这类问题的典型表现是屏幕背光黑掉以后，再唤醒时vblank计数停在唤醒前的值，应用层全部卡住。解决办法是在power_save路径里显式调用drm_vblank_off，在唤醒路径里再调用drm_vblank_on。

3.3 drm_crtc_vblank_on/off与Runtime PM的配合

MTK的显示驱动里，Runtime PM（运行时电源管理）对vblank的影响非常大。按标准流程，crtc在enable时需要把对应电源域打开，并调用drm_crtc_vblank_on，在disable时调用drm_crtc_vblank_off，然后关闭电源域。

但是在实际的应用场景中，如果系统频繁进入低功耗模式，crtc的suspend/resume时序和runtime PM的autosuspend可能产生竞争。我碰到过一次很隐蔽的问题，就是autosuspend delay设了3秒，而用户空间5秒才做一次GUI更新，结果就是：

每次GUI更新时display驱动已经从runtime suspend状态醒来并重新enable，但vblank的on/off处理时序和crtc的suspend/resume不对齐，导致vblank打开晚于硬件enable，中间有约1帧的窗口期，这一帧的vblank事件永远发不出去。应用层等待page flip会超时。

解决这个问题的标准姿势是，在suspend/resume回调里，不依赖runtime PM自动管理vblank，而是显式地在resume完成后主动调用drm_crtc_vblank_reset和drm_crtc_vblank_on，把计数器和状态规整。同时把enable/disable路径的vblank操作改为引用计数式：

if (crtc->state->enable && !crtc->state->active) drm_crtc_vblank_on(crtc); else if (crtc->state->enable && crtc->state->active) drm_crtc_vblank_reset(crtc);

这段逻辑看着简单，但真实解决了我在生产线设备上遇到的“第一次亮屏后后续亮屏都是花屏”的问题。

4. 多路显示与CRTC的绑定策略

4.1 MTK平台多路显示的CRTC分配方式

MTK的高端平台几乎都支持多路显示输出，比如一个屏走DSI0、一个屏走DP、还有一个屏走HDMI。这在汽车电子、平板设备、带副屏的设备上非常常见。

多路显示在DRM框架里的表现就是多个crtc实例。每个crtc实例通过dts的ports节点描述和具体的encoder/connector绑定。mtk_drm_crtc_init的时候会传入priv->crtc[0]、crtc[1]，依次注册到DRM core里。

但MTK有一个特殊情况，就是某些平台支持CWB（Concurrent Writeback）功能。所谓CWB是指同一条显示数据流同时可以输出到两路不同的接口。比如内屏和外屏显示同样的内容，但外部需求可能是内屏走OVL路径，外屏还要同时拿到同样的数据做采集或远程投屏。

在CWB的场景下，同一个crtc会输出到两个connector。这个在DRM的状态模型里其实是不标准的，因为DRM默认一个crtc只能连接一个connector。MTK的实现里通过一个虚拟的connector机制来包装CWB场景，在crtc的函数里会额外判断当前connector是不是CWB虚拟接口。

这里我建议大家不要死套DRM原版框架的约束去理解MTK的实现，因为DTSI里ports来管绑定，实际CRTC选择是受硬件data path限制的。查硬件手册比看DRM文档更快弄清到底哪路能绑定哪路。

4.2 CRTC与encoder的link：mode_fixup的坑

在KMS配置过程中，用户空间设置一个显示模式时，drm_atomic_check会调用每个crtc的mode_fixup函数。MTK在mode_fixup里做的事情包括：

• clamp像素时钟到panel支持的范围内
• 把mode进行微调使其符合MTK DPI_INT的时序重同步要求
• 记录mode变化以便后续计算vblank中断周期

我踩过一个坑，是用户空间设置了一个720x1280的竖屏mode，但MTK硬件DPI_INT要求输出的blanking interval至少是几行像素。mode_fixup没有修改时序，导致vblank周期只剩0.5ms，频率翻倍，上层GPU渲染队列全乱，动画严重卡顿。

解决方案是在mode_fixup里增加一个mode_validate，对比panel在dts里预设的时序参数，如果不匹配就调整blanking。这部分代码在mtk_drm_crtc_mode_fixup里：

static bool mtk_drm_crtc_mode_fixup(struct drm_crtc *crtc, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode) { // 根据平台能力，调整timing参数 adjusted_mode->htotal = mode->hdisplay + get_hblank(mtk_crtc); adjusted_mode->vtotal = mode->vdisplay + get_vblank_lines(mtk_crtc); // 校验clock adjusted_mode->clock = adjusted_mode->htotal * adjusted_mode->vtotal * mode->vrefresh / 1000; return true; }

简单说，就是让硬件输出的实际时长和用户预期的vblank节奏匹配起来。这块调好了，很多细微的动画卡顿问题不治而愈。

4.3 帧完成事件在双crtc模式下的投递顺序

双crtc并行输出时，事件投递顺序有个容易被忽略的细节。假设屏幕A是60Hz，屏幕B也是60Hz，但两边相位不同步。用户空间可能对屏幕A发起page flip并等待事件，屏幕B也发起page flip等待事件。两者的事件上报分别对应各自的vblank中断，正常情况下互不干扰。

但如果两个crtc共用一个irq共享中断处理函数，中断处理里如果用了同一个event变量或用同一个dp_lock锁保护某一资源，可能在高峰期因锁竞争把事件顺序搞乱。

MTK的实现是每个crtc独立管理自己的event和irq handler，但锁用的是dev->event_lock全局锁。这在双屏高刷新率（例如两个120Hz屏）下会产生明显的irq延迟，导致页翻转事件上报滞后。

我的建议是，如果平台支持并且你在改驱动，把event_lock改为per-crtc的锁，每个crtc单独用一把spinlock。实测在MT8195双屏4K30场景下，vblank上下文的锁等待时间从原来的平均80us降到20us左右。这个优化在标准DRM框架下需要动公共代码，但如果你的产品帧率一直跑不满，这笔投入值得。

5. 常见问题与调试思路盘点

5.1 花屏问题定位时CRTC侧的排查路径

花屏是所有显示调试者第一头疼的问题，且原因极多：framebuffer内存损坏、DMA时序错位、格式配置错误、带宽不足等。

从CRTC侧的代码看，我这里给出几条比较有效的排查路径：

第一，检查mtk_ddp_comp_layer_config是否正确收到plane的offset和stride。在常见RGB565/ARGB8888转换中，如果stride算错，你会看到屏幕内容是斜的、每行错开几个像素。这时把ftsan或dump_modeset打开看plane config信息，比对着dmesg猜要快得多。

第二，确认GEM对象物理地址是否连续。MTK显示硬件部分模块需要连续物理内存。如果用了通用CMA分配器导致非连续，CRTC配置寄存器地址时会出错，花屏通常伴随页错误。可以检查dma_addr是不是在cma区域预期范围。

第三，花屏是否只在特定分辨率或刷新率出现。如果是，检查CRTC输出的pixel clock是否超限。MTK各平台display clock源有限，比如DP_INT的时钟可能来自PLL的某个固定分频，如果mode的clock要求不匹配，硬件显示时会造成采样错位，体现为满屏斜条纹或随机噪点。

5.2 帧率不足时的vblank和时钟排查要点

帧率不足的情况我排过多年，多数情况下不是渲染能力问题，而是显示输出本身就没跑满。这里给一个排查清单：

• 先确认vblank中断频率。在cr_tc的irq入口计算1秒进来多少次。比如60Hz面板，每秒应该有60次（如果双帧触发会有120次，这取决于硬件）。如果只有一半，查是不是panel的反向扫描（EDS）或自动刷新模式导致。
• 确认pixel clock是否与mode匹配。用clk_get_rate函数取到当前clock，和mode->clock对比，偏差超过1%就要查PLL配置。
• 查有没有发生带宽限流。在MTK的DISPSYS中有bandwidth控制机制，当内存实时带宽超过阈值时，会主动降频或丢帧。CRTC代码里不会直接体现，但在mmsys的debugfs节点可以看到当前bw信息。
• 确认有没有不识别的延迟：比如mtk_ddp_comp_io_wait在等某些硬件为空时循环次数多、delay大。有些情况是硬件没正确返回idle状态，导致软件一直空转等待。

5.3 休眠唤醒后显示异常的CRTC处理细节

休眠唤醒场景，MTK的CRTC主要做三件事：保存上下文、关掉流水线、唤醒时恢复、再开流水线。听起来简单，但恢复顺序错一步就是黑屏或花屏。

我在代码里通常特别注意三处：

一是必须在关闭irq之前关闭vblank上报。否则唤醒过程中设备还没ready就来了frame done中断，处理函数里访问寄存器会返回全0，模式状态被污染。

二是寄存器备份集合要完整。MTK CRTC涉及的寄存器组非常多，包括0x14000000的OVL、0x14001000的RDMA、0x14002000的COLOR等，几百个寄存器。平台提供的suspend/resume回调里已经帮你做好了备份，但如果你在dts里额外添加了自定义comp，需要手动扩展备份集合。

三是唤醒完成后清理pending event。系统在休眠前可能还有未发送的vblank event，唤醒后需要根据hardware的实际状态决定丢弃还是补发一帧。如果直接补发，可能出现应用层提前收到事件并提交下一帧，但CRTC硬件还在恢复中导致丢帧。稳妥做法是在crtc_resume完成后调用drm_helper_resume_force_mode来强制重新应用一次mode，把上次未完成的状态清干净。

我在几个量产项目的实践中，总结出来一套无论哪个版本内核都适配的resume流程：

static void mtk_drm_crtc_resume(struct drm_crtc *crtc) { struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc); // 1. 恢复电源和时钟 mtk_ddp_comp_clk_enable(comp); // 2. 恢复寄存器备份 mtk_ddp_comp_resume(comp); // 3. 重新配置流水线 mtk_drm_crtc_start(mtk_crtc); // 4. 在第一个帧完成后通知core if (!crtc->state->active) drm_crtc_vblank_reset(crtc); drm_crtc_vblank_restore(crtc); }

顺序不能倒。我见过有同事把vblank_on放在clk_enable之前，结果dell到1/4概率唤醒后vblank中断不产生。

5.4 使用debugfs和trace工具观察CRTC状态

最后分享几个在MTK平台快速检查CRTC状态的工具和命令思路。

• 使用drm.debug模块参数打开DRM内部的日志输出：

echo 0x1f > /sys/module/drm/parameters/debug

这能把atomic操作的所有提交记录和state变化打到内核日志。排查配置问题时，我基本必开。

• 访问drm的debugfs节点，查看各对象状态：

cat /sys/kernel/debug/dri/0/state head /sys/kernel/debug/dri/0/framebuffers

从state里你能看到每个crtc当前的enable、active、mode、planes列表和各自的fb信息，非常直观。

• MTK mmsys在debugfs还有自己的节点：

cat /sys/kernel/debug/mtk_mmsys/reg

这个能看到当前DISPSYS内部各模块的寄存器状态。CRTC配置完以后，可以直接查看OVL/RDMA的地址寄存器是否与你预期的一致。

在这些工具组合之下，CRTC层面能出的问题基本都能定位到具体寄存器或调用栈，不用再靠加打印盲猜。

6. 总结一点个人体会：理解CRTC的核心是数据流与时序的控制抽象

这个系列写到第八篇，如果把DRM框架里CRTC、Plane、Encoder、Connector四个核心对象做一个比较，CRTC的复杂度首先体现在它所承担的职责过多：它既是模式的载体，又是vblank事件源，还要负责组件启停和数据流调度。MTK把这么多硬件细节塞进drm_crtc抽象里，文件的庞大和复杂是可以预期的。

对于刚接触MTK DRM驱动的人来说，我的建议是从原子操作的几个回调入手，先把atomic_check、atomic_begin、atomic_flush、atomic_enable、atomic_disable这条主链读懂，再回头理解vblank和低功耗时的隐藏逻辑，进步会快得多。文件里大量看似奇怪的分支条件和等待队列，本质上都是为了处理异步硬件动作和同步状态机——这部分多半只有你亲手调过一遍，才能真正体会到设计者的苦衷。

准备下一步读mtk_plane.c的话，可以把CRTC和Plane交互的挂接函数先梳理清楚，那样你会对layers从buffer到屏幕中间的路径有更整体的把握。