MTK平台LT9611桥接芯片驱动调试指南：从设备树到HDMI输出

简介面向 MediaTek 平台的 LT9611 显示驱动源码包适合嵌入式驱动开发与 BSP 工程师参考用于在 MTK 平台上适配 LT9611 芯片并实现默认 1080p 视频输出。压缩包共 5 个文件包括 3 个 C 驱动源文件与 2 个 DWS 配置文件整体仅 21KB结构精简C 文件覆盖 DSI 转 HDMI 的驱动逻辑DWS 文件用于引脚复用与 codegen 配置。资源同时包含 lk 与 kernel 阶段的驱动源文件便于对照启动早期和内核态的初始化流程也能理解显示输出设备在不同阶段的管理差异。已有 968 人浏览学习说明它在同类 MTK 调试项目中具有一定参考价值。这些文件能帮助开发者快速熟悉 LT9611 的驱动注册、时钟与显示通路配置减少从零移植和排查无显示、花屏等问题的弯路结合 DWS 配置还可快速定位引脚复用错误尤其适合需要输出 1080p 高清信号的智能电视、显示器转接等 MTK 设备方案。1. 一个工程名背后MTK 平台怎么把 HDMI 输出交给 LT9611如果你在某台 MTK 方案的内核源码目录里翻到mtk-lt9611_stomachhcc_lt9611_mtk这样的命名第一反应多半是方案公司发的桥接驱动包。LT9611 是一颗把 MIPI DSI 信号转成 HDMI 1.4 输出的桥接芯片MTK 的平板和工控板没有原生 HDMI TX 时十有八九会用它补一个 HDMI 口。我的血泪经验是这个工程名看着像乱码背后其实是完整的驱动源码、dts 配置和调试工具打包习惯。这篇文章只讲一件事拿到这类工程怎么在 MTK 平台上把 LT9611 这根 HDMI 链路调通避开我第一次做时踩过的坑。如果你手头是 MTK 平板方案、广告机或带 HDMI 输入的开发板这份流程可以直接照着走。2. LT9611 桥接芯片选型理由、工作模式和 MTK 内核里的驱动骨架我第一次拿到 LT9611 相关工程时第一反应是去翻处理器手册而不是芯片手册。这个顺序其实错了。MTK 平台里桥接芯片能不能起来更多取决于 DSI 输出时序和 bridge 驱动的挂载方式而不是 SoC 手册里的 GPIO 说明。2.1 为什么是 LT9611而不是直接做 HDMI我最早接触 LT9611是在一款 10.1 寸平板的改款项目上。产品经理要求加一个 HDMI 接口主板原来的 SoC 只有 DSI 输出。当时有两个选择换一颗带 HDMI TX 的 SoC或者在 DSI 后面搭一颗转换芯片。评估下来换 SoC 的硬件改动要重画基带部分固件、DDR 布线、电源树都要重新验证周期至少多两个月。搭 LT9611硬件改动只在显示链路上驱动由方案商给两三天就能亮起来。这是它存在的核心价值。MTK 与高通的差异在这里非常明显高通平台从 MDSS 到 HDMI 往往有现成的 display driver桥接芯片只是辅助MTK 的平板 SoC 则经常完全没有 HDMI controllerDSI 是唯一的输出途径。LT9611 挂在 DSI 之后本质上相当于把 DSI 协议翻译成 HDMI 协议所以调试时要同时懂 DSI 和 HDMI 两端。很多从高通项目转过来的人习惯先去搜板级 HDMI 的 DTS 属性结果在 MTK 平台上找不到就卡住了。LT9611 的标称能力是 HDMI 1.41080p60双 DSI 输入。单 DSI 4-lane RGB888 也能跑 1080p60但余量很小。如果产品未来要上 4K这颗芯片就不太合适。选型时要把这个边界跟项目经理说清楚不然项目后期会因为分辨率要求变更推倒重来到时候板子已经贴片了后悔药都没得吃。另外这颗芯片支持音频 SPI/I2S可以把 I2S 音频也打进 HDMI。对带扬声器的商显产品这功能很关键。但音频调试要注意 MTK 的 audio path 和 LT9611 的 audio enable 顺序顺序错了容易只有画面没有声音。这个问题单独查驱动看不出来要配合 alsa 的声卡 setting 一起看后面调试章节会提到。2.2 三个必看的工作模式DSI to HDMI、HDMI to DSI、以及 I2C 配置LT9611 芯片名称容易让人混淆它的核心角色是 DSI to HDMI但一些变体支持 HDMI to DSI 的反向桥接。驱动里通过 device id 区分。拿到工程先确认lt9611_read读到的 chip id 跟你代码里 switch-case 匹配。有次我们用了带 UXC 后缀的新料驱动还在用老 id 表结果每次 probe 都会 fail后来加了 id 才解决。所以不要以为驱动文件叫 lt9611就一定支持你板子上的那颗料。第二个需要关注的是双 DSI 模式。当你想跑 2560x1440 这类超过单路 DSI 带宽的分辨率时LT9611 可以用两路 DSI 同时输入。这个模式不是简单的“把两条 lane 接到同一个 controller”而是要在 DSI 驱动里设置dual-channel并且把两个 channel 的时序同步起来。MTK 平台上双通道 DSI 的配置散落在mtk_dsi.c和 dts 的port节点中一旦没配好现象往往是一半画面撕裂。第三个模式是 loopback通常只在产线测试时使用。芯片会把 HDMI 的输入回环到 DSI 端用来验证连接器是否焊接正常。这个模式在正常 Android 启动流程里不会用到但一些方案商提供的 init 脚本里会留一个lt9611_loopback_test命令。你在调试规格书之外的问题时可以用它隔离是 SoC DSI 的问题还是 LT9611 的问题省掉很多无效排查。I2C 配置是另一个容易翻车的点。LT9611 的寄存器页划分一般通过PAGE_SELECT寄存器切换。0x00 页是系统控制0x01 页是 HDMI 发送器0x02 页是 HDCP0x03 页是 DSI 接收器。还有一些厂商固化参数在 0x04 之后。驱动初始化流程会先复位芯片再切页配置 DSI 和 HDMI。你改动 dts 的 resolution 后如果没在对应页写 pixel clock等于没配。I2C 从地址常见的是0x3b但有的板子设计成0x29原理图和驱动可能不一致。驱动在 probe 阶段会读一个芯片 ID 寄存器读不到就会直接返回-ENXIO。拿不定时用i2cdetect扫描读到几个再对照原理图。芯片内部的寄存器还分成多个 page需要先写 page select 再访问功能寄存器。所以你在写初始化脚本时不要想当然地连续读写要先确认当前 page 指向哪里。2.3 内核里常见的驱动路径和 device tree 结构在 Linux DRM 子系统里桥接驱动通常通过drm_bridge_add注册。lt9611.c里实现drm_bridge_funcs的几个回调attach、mode_valid、enable、disable。MTK 的 DSI 驱动会在mtk_dsi_encoder_enable里调用 bridge chain 的pre_enable和enable。所以 LT9611 驱动能否工作跟 DSI 驱动的 trigger 时机强相关。最常见的错误是 bridge 已经 attach但 DSI 的encoder没有把bridge_list串起来。设备树节点一般挂在某个 I2C 总线下。下面是一个典型的节点模板按我们用的板子为例i2c3 { lt9611_bridge: lt96113b { compatible lontium,lt9611; reg 0x3b; reset-gpios pio 25 GPIO_ACTIVE_LOW; interrupt-parent pio; interrupts 26 IRQ_TYPE_EDGE_FALLING; vcc-supply reg_vcc3v3; mode dsi-to-hdmi; pinctrl-names default; pinctrl-0 lt9611_pins; status okay; }; }; pio { lt9611_pins: lt9611_pins { pinmux PINMUX_GPIO25__FUNC_GPIO25, PINMUX_GPIO26__FUNC_GPIO26; bias-pull-up; }; };这个节点里reset-gpios的极性非常关键。很多 MTK 板子的 reset 管脚外围有一个反向缓冲器原理图标注 ACTIVE_HIGH但实际跟驱动预期相反。如果驱动默认用GPIO_ACTIVE_LOW就会出现“reset 已经被拉高但其实芯片一直处于复位状态”的假象后面做什么都不对。vcc-supply也不可省。LT9611 需要 3.3V 和 1.8V 两组电有的板子只接了 3.3VI2C 能通HDMI TX 部分不工作现象非常隐蔽。拿到板子先量电压比查驱动快得多。MTK 平台还有一个坑pinctrl。HDMI 相关 GPIO 往往和 PCM、SPI 复用厂商的 pinctrl 驱动可能把同一 pin 配置成多个功能。你 dts 写了pinmux PINMUX_GPIO25__FUNC_GPIO25但另一处 i2c 或者 pcm 节点又占了 GPIO25编译能过运行时不生效。排查方法用 debugfs 看 pinctrl 的实际分配mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/pinctrl/pinctrl-handles如果发现同一个 pin 被两个节点引用优先改另一个节点或者跟硬件确认是不是 GPIO 选错。这类问题在常见的 MTK 参考设计上不多但定制板一多概率就上升了。3. 把 lt9611 驱动编进 MTK 平台从源码到 boot image 的最小流程这一章不讲复杂 build system只讲最快走通的一条路在 MTK 内核源码树里编出 boot.img再用 MTK 刷机工具烧进去。整个过程最耗时间的不是编译而是搞错分支和白折腾 dts。3.1 先确认内核版本和驱动源不要拿错分支MTK 平台的内核版本非常混乱有 Linux 4.4、4.9、4.14、4.19、5.4、5.15 等等。LT9611 驱动在不同版本里的 DRM bridge API 完全不同。老内核用drm_bridge_attach(encoder, bridge, NULL)新内核要求第三个参数是 previous bridge。直接互换会出现编译错误或者运行时空指针。所以不要自己从网上随便拷一个驱动更不要指望主线内核版本能直接套在 MTK 方案上。正确做法是先把包里的drivers/gpu/drm/bridge/lontium/和arch/arm64/boot/dts/mediatek/原封不动放进对应的内核分支再确认 Kconfig 里有没有CONFIG_DRM_LONTIUM_LT9611。如果找不到这个选项多半是 bridge 目录下的 Makefile 没有把lontium/包含进来。检查drivers/gpu/drm/bridge/Makefile是否有obj-y lontium/。我一般会先在目标内核上执行一次干净编译确认 baseline 没有报错再合入驱动。这样后续任何编译问题都能确定是驱动代码引入的而不是原内核本来就坏的。如果编译报错提示struct drm_bridge缺少某个字段大概率是拿错了内核分支。把驱动里的drm_bridge_funcs和当前内核头文件的定义对比一下几分钟就能定位。还有一个容易被忽略的点源码包里可能同时存在lt9611.c和lt9611_uxc.c或者有多个平台文件夹。MTK 方案商经常把多个项目的驱动合到一个包Makefile 用不同的 Kconfig 符号区分。不要只看文件名要看Makefile里实际编的是哪个对象。我见过有人改了lt9611.c编译刷机后没有任何变化折腾半天才发现 Makefile 编的是lt9611_uxc.c。3.2 dts 节点怎么配reg、reset-gpio、supply 和中断上一章已经给出了模板这里补充几个容易配错的点。reg地址不是随便填的它必须和 LT9611 的 I2C 从地址一致并且 I2C 控制器地址位宽要支持 7-bit。多数板子用 7-bit 地址直接填0x3b没问题。如果驱动里用的是i2c_new_device或者i2c_get_match_data还要确认平台 i2c 总线号跟 dts 里的i2c3对应不然驱动挂在 0 号总线实际芯片在 3 号总线上读不到任何数据。reset-gpios的使用还有一个细节驱动 probe 时会把 reset 拉低再拉高如果 GPIO 默认方向和备用功能被其他设备占用probe 就会卡在devm_gpiod_get_optional。检查 pinctrl 是不是把该管脚复用成了GPIO25__FUNC_GPIO25而不是别的功能。有的 SDK 要求 reset 是开漏输出需要在 dts 里加drive-open-drain否则拉低时电平不够芯片一直处于复位状态。interrupts不一定要配。LT9611 的 HPD 事件可以通过中断上报给 DRM但如果你的板子没有把 HDMI 热插拔连接到 SoC 的 GPIO那就千万别配否则 probe 阶段申请中断失败导致整个 bridge 初始化失败。没有 HPD 时靠轮询 EDID 也能工作只是热插拔响应慢几秒。我习惯先不配中断把基本显示调通后再加加之前先确认中断 GPIO 上确实有电平跳变。下面把几个关键属性的常见错误整理成一个表方便对照排查属性作用常见错误compatible匹配驱动写错成lt9611uxc导致不 proberegI2C 从地址与原理图不一致reset-gpios复位控制极性反了或 pinctrl 被占用vcc-supply主电源 regulator供电没起或延时不足interruptsHPD 中断板子没有 HPD 硬线却配了中断3.3 编译并生成 boot.img一条命令与参数说明MTK 的编译流程通常基于make bootimage而不是make Image。下面是我在 MT8167 平台上的最小流程export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- # 先加载方案默认配置 make mt8167_defconfig # 用 scripts/config 直接打开桥接驱动选项避免手工 menuconfig scripts/config --file .config -e CONFIG_DRM_LONTIUM_LT9611 make olddefconfig # 编设备树 make dtbs # 编 boot.img make bootimage -j8这里scripts/config是内核自带工具直接修改.config里的符号不用进 menuconfig。CONFIG_DRM_LONTIUM_LT9611如果已经被编译成模块还要确认镜像里有没有把lt9611.ko放到vendor/lib/modules否则 probe 会因为模块没加载而失败。MTK 的 Android 内核通常把 module 放 vendor_boot需要单独执行make modules_install按分区路径拷贝。make bootimage会调用 MTK 的打包脚本把 kernel 和 dtb 封装成 Android boot image。如果你的平台不是 MT8167把mt8167_defconfig换成方案自己的 defconfig 即可。注意make dtbs之后必须确认arch/arm64/boot/dts/mediatek/*.dtb的修改时间更新了有时候 Makefile 依赖没触发会用旧 dtb 打包这是后续黑屏的常见来源。烧录时操作系统需要先装好 MTK 端口驱动安装。Windows 下接入设备如果设备管理器里始终是未知设备就是 VCOM 驱动没装。装好之后用 SP Flash Tool 或者方案商提供的下载工具选择boot分区镜像对照 scatter 文件烧写。SP Flash Tool 是 MTK 刷机工具里最常用的一种但版本差异容易导致DA mismatch优先用方案商在 README 里指定的版本。如果 bootloader 还没解锁先做好 mtk client 解 bl 操作不然后面刷任何分区都会报ERROR : S_BROM_CMD_STARTCMD_FAIL。解锁步骤一般是先使能 OEM 解锁再执行fastboot oem unlock然后重启进 bootloader。注意解锁之后不要恢复原厂 lock否则可能变砖。这是血泪教训。4. LT9611 调试避坑5 个真实问题的现象、原因与解决这个标题看起来简单实际是我在三个项目里反复踩过的坑。下面每条都按“现象、原因、解决”整理你可以直接拿着去对照 dmesg 和寄存器。4.1 上电后 HDMI 黑屏但内核日志里 lt9611 已经 probe 成功现象开机后 dmesg 有lt9611 3-003b: LT9611 initialization done但接上 HDMI 显示器一直是黑屏。原因probe 成功只代表 I2C 通信正常不代表 DSI 链路已经传数据。最常见的根因是 LT9611 在 probe 时第一次读 EDID 读不到HPD 还没有拉高主控侧不知道对面显示器到底支不支持当前时序。另一种根因是 DSI 的 clock-frequency 与 LT9611 要求的 HDMI 像素时钟差太多PLL 整不出来。解决先用cat /sys/class/drm/card0-DSI-1/status看 connector 状态如果显示connected但黑屏就是时序问题。接着在 dmesg 里查 DSI PLL 和 clock 相关日志确认 DSI bitrate 在合理范围。我一般会加一段调试打印把mode-clock和mode-htotal * mode-vtotal * 60输出的值对比偏差超过几个百分点就是模式没设对。dmesg | grep -E lt9611|DSI|HDMI cat /sys/class/drm/card0-DSI-1/status如果 DSI 端读到的 EDID 是空的检查 LT9611 的 HPD 引脚是否接到中断对应的 GPIO或者干脆去掉 dts 里的 interrupt让驱动走轮询。EDID 轮询在 Linux DRM 里通过drm_helper_hpd_irq_event触发没有检测到连接时显示器拔插不会自动重试需要在调试阶段手动触发connector-funcs-detect。4.2 分辨率超出面板参数画面闪屏现象设置 1920x108060 输出画面上下滚动、间断性闪烁偶尔花屏。原因LT9611 的 HDMI 输出能力虽然标称 1080p60但 MIPI DSI 的带宽要算上 blanking。很多 MTK 方案的最高 DSI clock 有限RGB888 的 60fps 和 30fps 的 bitrate 差一倍超出后数据丢失就是闪烁翻车。解决先算实际需求pixel_clock (Hz) htotal * vtotal * refresh_rate dsi_bitrate (bps) pixel_clock * bits_per_pixel / lanes以 1920x108060 为例htotal 2200、vtotal 1125、bpp 24、lanes 4算出 DSI bitrate 约 891 Mbps。如果平台 DSI 最高只有 800 Mbps就必须把刷新率降到 50 或减少色深到 RGB565。驱动节点里的bus-format和clock-frequency要一起改不能只改一个。只调clock-frequency而bus-format还写 RGB888驱动仍会按 24bpp 计算 lane 数结果不变。还有一个容易忽视的因素是 LT9611 内部 MIPI receiver 的 lane speed 上限。不同批次芯片规格可能不同方案商驱动里通常会在lt9611_mipi_set里写死一个0x81之类的配置。如果你的屏参很高可以尝试把 DSI 的non-continuous-clock打开有时能把多余 EMI 和抖动压下去虽然没有提升带宽但画面稳定不少。4.3 I2C 读取失败导致驱动初始化崩溃现象probe 直接报failed to read chip id或lt9611_init error -110有时候整个 DSI probe 失败屏幕连背光都不亮。原因除了地址不对更隐蔽的是 LT9611 的供电还没起来就被访问了。dts 里vcc-supply虽然配了但 regulator 的startup-delay-us和settling-time-us没设置驱动读写 I2C 时芯片还在上电复位。解决先在 I2C 总线上手动读一次 chip id用下面命令快速验证地址和总线i2cdetect -y -r 3 i2ctransfer -y 3 w10x3b 0x08 r1如果读不到用示波器量 reset 和 VCC 上电时序。解决方式有两种一种是在vcc-supply的 regulator 节点加启动延时另一种是在驱动 probe 函数开头加msleep(50)。我更喜欢前者功耗表现更正常而且不用改代码。如果 I2C 地址对但仍然报-ENXIO检查 I2C 总线上是否有多个设备冲突。LT9611 的 address pin 是硬件决定的同一总线上可能还有其他从设备占用地址。这时候要么改目标芯片地址要么换到空闲 I2C。千万不要用i2c-dev随便乱读可能导致其他从设备进入异常状态。4.4 休眠唤醒后 LT9611 不恢复输出现象Android 休眠再唤醒后 dmesg 里没有报错但 HDMI 画面消失拔插一次才好。原因MTK 平台在 suspend 时把 DSI 输出关掉同时把 LT9611 的供电或 reset 拉低。resume 时 MTK 只恢复 DSI controller不会重新执行 LT9611 的初始化芯片内部状态已经丢了。解决在 lt9611_ops 里实现atomic_check、atomic_mode_set并在其中调用重新初始化函数。如果驱动版本没有pm_ops可以在mtk_dsi的resume里调用 bridge 的post_disablepre_enable。还有一个土办法就是把 LT9611 的供电接成“常开”reset 由 GPIO 拉高不让它在 suspend 期间掉电。这个方案不算优雅但在没有驱动维护能力的产品上非常可靠。更彻底的排查方法是先确认 suspend 期间到底有没有掉电。在 dmesg 里加一个late_resume打印量 LT9611 的 VDD 和 reset 电平。如果掉电就是 PM_SUSPEND 的 regulator 行为如果没掉电但驱动还是丢了配置那多半是 DSI 的 clock 被关了。按照从电源到时钟的链路逐段查比瞎试pm_runtime_put_sync有用得多。4.5 修改 dts 后没生效重刷 boot.img 却是旧状态现象改了 dts 里reset-gpios的 GPIO 编号编译、烧录后 dmesg 打印的 pin 还是原来的值。原因MTK 的 boot 镜像里除了 kernel还有 dtb 或者 dt.img。make dtbs生成的新 dtb 不一定被打进 boot.img因为 Makefile 依赖经常不追踪.dtb文件变化。另外散件目录里可能有多个 dtbSP Flash Tool 烧的 dtb 分区和你改的不是同一个文件。解决检查 boot.img 里面的 dtb 内容。用方案商提供的mkbootimg解包mkbootimg --unpack boot.img xxd kernel_dtb.raw | head确认你改的 GPIO 出现在 raw data 里。如果没有就是编译打包步骤错了。也可以直接单独烧 dtb 分区把arch/arm64/boot/dts/mediatek/xxx.dtb按 scatter 文件里DTB分区名称烧入。不要依赖make bootimage内部逻辑裸编后逐个确认文件时间戳能省掉一个下午。还有一个坑是 Android 的 boot 镜像可能同时包含 DTB 和 recovery ramdisk你改了 dts 但只刷boot分区而vendor_boot里有另一份 dtb。现在新平台都流行 vendor_boot 存放 dtb这种情况下要用androidboot参数指定dtb_index。检查fastboot getvar current-slot确认两个 slot 都刷了新镜像否则 AB 系统切换时又会回到旧 dts。5. 从黑盒到可验证把 LT9611 的寄存器 dump 和时钟状态做成调试入口这部分讲一个我最后沉淀下来的习惯让 LT9611 的可调试性从“厂商没给工具”变成“自己也能出证据”。LT9611 是桥接芯片内部寄存器很多逐页看太慢。我一般在驱动里加一个 debugfs 入口把关键页的寄存器全部导出来。5.1 在 debugfs 里暴露 LT9611 寄存器在lt9611_probe后面加几行 debugfs 创建逻辑#include linux/debugfs.h static int lt9611_regs_show(struct seq_file *s, void *unused) { struct lt9611 *lt s-private; u8 page; for (page 0; page 0x08; page) { /* 切换 page 后连续读 0x10 个寄存器 */ lt9611_write(lt, LT9611_PAGE_SELECT, page); seq_printf(s, page %u:\n, page); for (i 0; i 0x10; i) seq_printf(s, [%02x] %02x\n, i, lt9611_read(lt, LT9611_REG_BASE i)); } return 0; } DEFINE_SHOW_ATTRIBUTE(lt9611_regs);这段代码不用跟具体 SDK 完全一致重点是把LT9611_PAGE_SELECT和读函数当成抽象接口替换成你驱动里实际存在的函数即可。添加后调试时直接mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/lt9611/regs就能拿到一排寄存器值和初始化失败后的状态对比能快判断是不是 PLL 失锁。5.2 用 dmesg 和寄存器快照快速定位链路没有串口的 MTK 板子我一般先用 adb over ethernet 连进去。MTK Android 以太网配置是在设置里打开“以太网”然后adb connect 板子IP实测比 USB 稳定。连进去之后按顺序执行dmesg | grep -E lt9611|DSI|HDMI cat /sys/kernel/debug/lt9611/regs /data/local/tmp/lt9611_regs.txt把lt9611_regs.txt拉出来和上次正常的快照 diff能直接看到哪一页寄存器被初始化脚本改掉。很多看起来像玄学的闪屏其实都是某个寄存器的 bit 没写对。5.3 每次调试的寄存器快照留在工程目录最后是一个简单习惯每次调完参数把 dmesg 和 debugfs 寄存器快照存到工程目录用日期命名。dmesg dmesg_$(date %Y%m%d_%H%M).log cat /sys/kernel/debug/lt9611/regs lt9611_regs_$(date %Y%m%d).txt这个习惯最开始是被项目里“改了一个参数之后画面好了但回退代码后画面又坏了”搞怕了才养成的。后来发现对比两次快照能直接看到是哪一次改动让画面恢复很多靠记忆回滚的状态就不会再丢。回到mtk-lt9611_stomachhcc_lt9611_mtk这个工程我现在的第一步是先看 git diff不急着看原理图然后确保 debugfs 入口已经编译进去再做任何修改前存一份寄存器快照。这套流程能少走不少弯路希望帮到你。本文还有配套的精品资源点击获取