19.1 printk与dev_dbg驱动调试的“听诊器”printk是内核调试的基本工具。但很多人用错了。我见过有人在内核里到处刷printk结果系统直接卡死。为什么因为printk是同步的刷太快会阻塞。核心原则调试阶段用printk稳定后换成dev_dbg。dev_dbg可以通过动态调试开关控制不影响性能。19.1.1 printk的级别选择printk有8个级别从KERN_EMERG到KERN_DEBUG。我常用的就三个KERN_ERR (3)真正出错了才用。比如寄存器读写失败、时序超时。KERN_WARNING (4)可能有问题但不致命。比如分辨率不匹配、时钟偏差。KERN_INFO (6)正常流程信息。比如初始化完成、模式切换成功。千万别在中断处理函数里用KERN_DEBUG级别的printk。我曾经在MTK8678的DSI中断里加了一堆调试打印结果屏幕直接撕裂——因为打印占用了太多时间导致中断响应延迟。19.1.2 dev_dbg与动态调试dev_dbg比printk高级在哪它可以通过/sys/kernel/debug/dynamic_debug/control动态开关。你想想看产品发布后客户说屏幕偶尔闪一下你总不能重新编译内核吧// 打开某个文件的调试信息 echo file mtk_drm_dsi.c p /sys/kernel/debug/dynamic_debug/control // 只打开某个函数的调试 echo func mtk_dsi_enable p /sys/kernel/debug/dynamic_debug/control // 关闭所有调试 echo file mtk_drm_dsi.c -p /sys/kernel/debug/dynamic_debug/control我的习惯在驱动初始化时用dev_dbg打印关键寄存器的默认值。这样出问题时直接打开动态调试就能看到初始状态不用重新烧录固件。19.2 寄存器dump分析直接看硬件状态printk只能看到软件层面的信息。但显示驱动的问题很多时候是硬件状态不对。这时候就得靠寄存器dump了。19.2.1 关键寄存器组MTK8678的显示控制器有几百个寄存器。但调试时我重点关注这几组寄存器组偏移地址调试要点DSI控制寄存器0x1400_0000 ~ 0x1400_00FF检查DSI是否进入LP模式、时钟是否稳定时序发生器0x1400_0100 ~ 0x1400_01FF验证HFP、HBP、VFP、VBP是否与panel匹配FIFO状态0x1400_0200 ~ 0x1400_020F看FIFO是否溢出或空这会导致花屏中断状态0x1400_0300 ~ 0x1400_030F确认是否有未处理的中断比如CRC错误19.2.2 实战dump并分析我写了一个简单的dump函数专门用来抓取显示控制器的寄存器快照static void mtk_dsi_dump_regs(struct mtk_dsi *dsi) { int i; void __iomem *base dsi-regs; pr_info( DSI Register Dump \n); // 先看控制寄存器 for (i 0; i 0x100; i 4) { u32 val readl(base i); if (val) // 只打印非零值减少干扰 pr_info(DSI[0x%04x] 0x%08x\n, i, val); } // 再看时序寄存器 pr_info(--- Timing Registers ---\n); pr_info(HSA: %d, HBP: %d, HFP: %d\n, readl(base DSI_HSA), readl(base DSI_HBP), readl(base DSI_HFP)); // 最后看状态寄存器 u32 status readl(base DSI_STATUS); pr_info(DSI Status: 0x%08x\n, status); if (status DSI_STATUS_FIFO_EMPTY) pr_warn(FIFO is empty! Possible underflow.\n); if (status DSI_STATUS_FIFO_FULL) pr_warn(FIFO is full! Possible overflow.\n); }注意寄存器dump要在显示控制器工作时进行。如果屏幕已经黑了很多寄存器可能已经复位了dump出来的数据没有参考价值。我建议在初始化完成后、第一次刷屏前做一次dump作为基线。19.3 示波器测量时序眼见为实软件调试再厉害也看不到真实的电信号。示波器才是最终的裁判。我记得有一次客户说屏幕偶尔闪一下printk和寄存器dump都看不出问题。最后用示波器一抓发现VSYNC的上升沿有毛刺——原来是电源纹波太大。19.3.1 测量哪些信号对于MTK8678的多屏显示我建议至少抓这几个信号VSYNC帧同步信号。看周期是否稳定有没有抖动。HSYNC行同步信号。看脉宽是否准确有没有漏脉冲。DCLK像素时钟。看频率是否达标占空比是否50%。DE数据使能信号。看有效数据区间是否正确。19.3.2 时序参数验证拿到示波器波形后怎么判断对不对我一般按这个流程来先看频率DCLK的频率必须跟panel要求的完全一致。差1%都可能出问题。再看周期VSYNC的周期就是帧率。比如60Hz周期应该是16.67ms。如果偏了说明时钟有问题。最后看边沿上升沿和下降沿的斜率。太缓说明驱动能力不够太陡可能有反射。我的经验示波器探头的地线要尽量短。我见过有人用长地线夹子结果测出来的波形全是噪声。用弹簧地线或者直接焊在测试点上效果会好很多。19.3.3 常见时序问题我整理了几个在MTK8678项目里遇到过的典型问题现象示波器波形根因解决方法屏幕上半部分正常下半部分花屏VSYNC周期不稳定有时多一个脉冲帧缓冲区更新与VSYNC不同步使用双缓冲在VSYNC中断中切换屏幕有横条纹HSYNC脉宽忽大忽小行同步信号受干扰增加HSYNC信号的滤波电容屏幕闪烁DCLK频率抖动PLL锁相环不稳定检查PLL的参考时钟和环路滤波器屏幕偏色DE信号提前结束HFP或HBP配置错误对照panel datasheet重新计算时序19.4 三板斧配合使用这三种调试手段不是孤立的。我一般按这个顺序来先用printk确认软件流程是否走通有没有报错。再用寄存器dump确认硬件状态是否跟预期一致。最后上示波器确认实际电信号是否达标。举个例子。有一次调试双屏异显副屏一直不亮。printk显示初始化成功寄存器dump也看不出问题。最后用示波器一抓发现副屏的VSYNC根本没输出——原来是时钟树配置错了副屏的PLL没使能。记住printk告诉你“软件认为发生了什么”寄存器dump告诉你“硬件当前是什么状态”示波器告诉你“实际信号是什么样子”。三者结合才能快速定位问题。嗯调试技巧就这些。下一章我会讲性能优化包括如何减少帧延迟、如何优化带宽。到时候再聊。
19.1 printk与dev_dbg驱动调试的“听诊器”printk是内核调试的基本工具。但很多人用错了。我见过有人在内核里到处刷printk结果系统直接卡死。为什么因为printk是同步的刷太快会阻塞。核心原则调试阶段用printk稳定后换成dev_dbg。dev_dbg可以通过动态调试开关控制不影响性能。19.1.1 printk的级别选择printk有8个级别从KERN_EMERG到KERN_DEBUG。我常用的就三个KERN_ERR (3)真正出错了才用。比如寄存器读写失败、时序超时。KERN_WARNING (4)可能有问题但不致命。比如分辨率不匹配、时钟偏差。KERN_INFO (6)正常流程信息。比如初始化完成、模式切换成功。千万别在中断处理函数里用KERN_DEBUG级别的printk。我曾经在MTK8678的DSI中断里加了一堆调试打印结果屏幕直接撕裂——因为打印占用了太多时间导致中断响应延迟。19.1.2 dev_dbg与动态调试dev_dbg比printk高级在哪它可以通过/sys/kernel/debug/dynamic_debug/control动态开关。你想想看产品发布后客户说屏幕偶尔闪一下你总不能重新编译内核吧// 打开某个文件的调试信息 echo file mtk_drm_dsi.c p /sys/kernel/debug/dynamic_debug/control // 只打开某个函数的调试 echo func mtk_dsi_enable p /sys/kernel/debug/dynamic_debug/control // 关闭所有调试 echo file mtk_drm_dsi.c -p /sys/kernel/debug/dynamic_debug/control我的习惯在驱动初始化时用dev_dbg打印关键寄存器的默认值。这样出问题时直接打开动态调试就能看到初始状态不用重新烧录固件。19.2 寄存器dump分析直接看硬件状态printk只能看到软件层面的信息。但显示驱动的问题很多时候是硬件状态不对。这时候就得靠寄存器dump了。19.2.1 关键寄存器组MTK8678的显示控制器有几百个寄存器。但调试时我重点关注这几组寄存器组偏移地址调试要点DSI控制寄存器0x1400_0000 ~ 0x1400_00FF检查DSI是否进入LP模式、时钟是否稳定时序发生器0x1400_0100 ~ 0x1400_01FF验证HFP、HBP、VFP、VBP是否与panel匹配FIFO状态0x1400_0200 ~ 0x1400_020F看FIFO是否溢出或空这会导致花屏中断状态0x1400_0300 ~ 0x1400_030F确认是否有未处理的中断比如CRC错误19.2.2 实战dump并分析我写了一个简单的dump函数专门用来抓取显示控制器的寄存器快照static void mtk_dsi_dump_regs(struct mtk_dsi *dsi) { int i; void __iomem *base dsi-regs; pr_info( DSI Register Dump \n); // 先看控制寄存器 for (i 0; i 0x100; i 4) { u32 val readl(base i); if (val) // 只打印非零值减少干扰 pr_info(DSI[0x%04x] 0x%08x\n, i, val); } // 再看时序寄存器 pr_info(--- Timing Registers ---\n); pr_info(HSA: %d, HBP: %d, HFP: %d\n, readl(base DSI_HSA), readl(base DSI_HBP), readl(base DSI_HFP)); // 最后看状态寄存器 u32 status readl(base DSI_STATUS); pr_info(DSI Status: 0x%08x\n, status); if (status DSI_STATUS_FIFO_EMPTY) pr_warn(FIFO is empty! Possible underflow.\n); if (status DSI_STATUS_FIFO_FULL) pr_warn(FIFO is full! Possible overflow.\n); }注意寄存器dump要在显示控制器工作时进行。如果屏幕已经黑了很多寄存器可能已经复位了dump出来的数据没有参考价值。我建议在初始化完成后、第一次刷屏前做一次dump作为基线。19.3 示波器测量时序眼见为实软件调试再厉害也看不到真实的电信号。示波器才是最终的裁判。我记得有一次客户说屏幕偶尔闪一下printk和寄存器dump都看不出问题。最后用示波器一抓发现VSYNC的上升沿有毛刺——原来是电源纹波太大。19.3.1 测量哪些信号对于MTK8678的多屏显示我建议至少抓这几个信号VSYNC帧同步信号。看周期是否稳定有没有抖动。HSYNC行同步信号。看脉宽是否准确有没有漏脉冲。DCLK像素时钟。看频率是否达标占空比是否50%。DE数据使能信号。看有效数据区间是否正确。19.3.2 时序参数验证拿到示波器波形后怎么判断对不对我一般按这个流程来先看频率DCLK的频率必须跟panel要求的完全一致。差1%都可能出问题。再看周期VSYNC的周期就是帧率。比如60Hz周期应该是16.67ms。如果偏了说明时钟有问题。最后看边沿上升沿和下降沿的斜率。太缓说明驱动能力不够太陡可能有反射。我的经验示波器探头的地线要尽量短。我见过有人用长地线夹子结果测出来的波形全是噪声。用弹簧地线或者直接焊在测试点上效果会好很多。19.3.3 常见时序问题我整理了几个在MTK8678项目里遇到过的典型问题现象示波器波形根因解决方法屏幕上半部分正常下半部分花屏VSYNC周期不稳定有时多一个脉冲帧缓冲区更新与VSYNC不同步使用双缓冲在VSYNC中断中切换屏幕有横条纹HSYNC脉宽忽大忽小行同步信号受干扰增加HSYNC信号的滤波电容屏幕闪烁DCLK频率抖动PLL锁相环不稳定检查PLL的参考时钟和环路滤波器屏幕偏色DE信号提前结束HFP或HBP配置错误对照panel datasheet重新计算时序19.4 三板斧配合使用这三种调试手段不是孤立的。我一般按这个顺序来先用printk确认软件流程是否走通有没有报错。再用寄存器dump确认硬件状态是否跟预期一致。最后上示波器确认实际电信号是否达标。举个例子。有一次调试双屏异显副屏一直不亮。printk显示初始化成功寄存器dump也看不出问题。最后用示波器一抓发现副屏的VSYNC根本没输出——原来是时钟树配置错了副屏的PLL没使能。记住printk告诉你“软件认为发生了什么”寄存器dump告诉你“硬件当前是什么状态”示波器告诉你“实际信号是什么样子”。三者结合才能快速定位问题。嗯调试技巧就这些。下一章我会讲性能优化包括如何减少帧延迟、如何优化带宽。到时候再聊。
