kernel6.1 MTK修改屏幕物理分辨率常见问题

Question

在基于Kernel 6.1的MTK平台中，修改屏幕物理分辨率时常出现显示异常或无法点亮屏幕的问题。常见表现为：修改dts中display节点的panel-timing参数后，内核启动日志显示解析正常，但LCD初始化失败或画面撕裂、偏移。其主要原因包括：未同步更新ddp_manager路径时序配置、lcm driver中硬编码分辨率限制、以及未正确调整CMD模式下的HS/PLLS控制参数。此外，Android框架层对dpi与分辨率的耦合判断也可能导致系统进入错误的显示模式。需确保kernel与lk阶段传递的display参数一致，并验证mipi-dsi带宽是否支持新分辨率。

Answer 1

基于Kernel 6.1的MTK平台屏幕分辨率修改问题深度解析

1. 问题背景与现象描述

在基于MTK平台且运行Linux Kernel 6.1的设备中，开发者常需根据硬件定制需求修改LCD面板的物理分辨率。典型操作是在设备树（DTS）文件中调整panel-timing节点下的时序参数，如hactive、vactive、hsync-len等。

尽管内核启动日志显示dts成功解析新timing配置，但实际表现为：

• LCD无法点亮（背光亮但无图像）
• 画面撕裂或水平/垂直偏移
• 初始化阶段报错“ddp_aal_set_lcm_resolution fail”
• MIPI DSI控制器进入频繁重传或超时状态

这些问题表明，仅修改DTS中的timing参数不足以完成分辨率适配。

2. 根本原因分析框架

从系统架构角度出发，显示子系统涉及多个层级协同工作。以下是导致问题的主要技术维度：

层级	组件	潜在问题点
Bootloader (LK)	lcm_drv.h/.c	未同步更新panel_info.resolution
Kernel DTS	panel-timing	timing参数不完整或格式错误
Kernel Driver	lcm driver (.c)	硬编码width/height限制
Display Pipeline	ddp_manager.c	路径配置未匹配新分辨率
MIPI 控制器	dsi_phy_config	HS频率或PLL未重算
Framework	SurfaceFlinger, DisplayManager	DPI与res非线性映射触发fallback模式

3. 深度排查路径与解决方案

3.1 确保LK与Kernel参数一致性

MTK平台采用LK（Little Kernel）作为pre-loader加载LCM驱动。若LK中定义的分辨率与kernel dts不一致，会导致mipi链路训练失败。

// 在project/lcm/xxx/xxx_lcm.c中检查： static struct LCM_DRIVER xxx_lcm_drv = { .name = "xxx", .set_params = lcm_set_params, ... }; void lcm_set_params(struct LCM_SETTING_TABLE *para) { memset(para, 0, sizeof(struct LCM_SETTING_TABLE)); para->resolution = LCM_HDMI_1920_1080; // 必须与dts vactive/hactive匹配 para->physical_width = 68; // mm para->physical_height = 38; }

建议：将resolution改为动态宏定义，并通过编译选项统一管理。

3.2 更新DDP Manager时序路径配置

MTK的Display Data Path（DDP）模块负责OVL→RDMA→DSI的流水线调度。当分辨率变更后，必须重新校准各模块带宽和行同步周期。

关键函数位于drivers/gpu/mediatek/disp/mtk_disp_mgr.c：

int mtk_ddp_comp_init(struct mtk_ddp_comp *comp, ...) { if (comp_id == DDP_COMPONENT_OVL) { cfg.w = new_hactive; cfg.h = new_vactive; mtk_ovl_layer_config(comp, 0, &cfg); } }

需验证mtk_disp_mutex_set_video_mode()中是否正确设置VS/DE时序偏移。

3.3 解决LCM Driver硬编码限制

许多厂商提供的LCM驱动源码中存在如下代码片段：

if (w != 1080 || h != 2400) { LCD_LOGE("Unsupported resolution: %dx%d", w, h); return -1; }

此类判断会直接阻止非标分辨率初始化。应移除或替换为条件编译宏控制。

3.4 调整CMD模式下HS Clock与PLL配置

对于CMD模式屏，MIPI DSI的High Speed时钟频率直接影响数据吞吐能力。新分辨率可能超出原有PHY带宽。

计算公式：

Bandwidth(Mbps) = (Htotal × Vtotal × fps × bpp) / (lane_num × 8)

例如：2K@60Hz，4-lane，RGB888（24bpp）需约：

(1500×3200×60×24)/(4×8) ≈ 1080 Mbps per lane → 需PLL输出≥1.1Gbps

需在dsi_phy_config()中调整hs_trail, clk_hs_prpr等寄存器值。

3.5 Android框架层DPI耦合干扰处理

Android系统通过build.prop中的ro.sf.lcd_density推断显示模式。若分辨率变化但DPI未调优，可能导致SurfaceFlinger使用错误的transform matrix。

建议策略：

1. 保持density与ppi数学一致：dpi = √(w² + h²) / 尺寸(inch)
2. 强制重启SurfaceFlinger：stop surfaceflinger && start surfaceflinger
3. 使用adb shell wm size验证虚拟分辨率映射

4. 验证流程与调试手段

推荐使用以下流程图进行系统化验证：

        graph TD
            A[修改DTS panel-timing] --> B{LK与Kernel resolution一致?}
            B -- 是 --> C[检查lcm driver硬编码]
            B -- 否 --> D[同步LK中resolution字段]
            C --> E{DDP Manager已适配?}
            E -- 否 --> F[更新mtk_disp_mgr路径参数]
            E -- 是 --> G[计算MIPI带宽需求]
            G --> H{PLL支持目标速率?}
            H -- 否 --> I[调整dsi_phy_config参数]
            H -- 是 --> J[启动Android框架]
            J --> K{画面正常?}
            K -- 否 --> L[检查SurfaceFlinger日志及dpi设置]
            K -- 是 --> M[完成]
    

5. 典型调试日志对照表

现象	内核日志关键词	定位方向
黑屏但背光亮	"DSI out of sync"	MIPI clock不稳定
画面左移/撕裂	"DE spike detected"	DDP DE timing偏移
快速重启	"lcm_compare_id failed"	LK与kernel ID不匹配
卡住于logo	"wait_for_idle timeout"	OVL/RDMA死锁
花屏	"CRC error in DSI packet"	lane skew未补偿
低帧率	"underflow detected"	bandwidth不足
闪屏	"vdo mode start fail"	VSA/VBP过小
无法进UI	"Failed to create composition"	SF合成尺寸越界
自动降频	"thermal throttle display"	功耗过高触发热机制
冷启动失败	"lcm init timeout"	reset sequence延迟不足