i.MX8MQ平台LT8619c HDMI转LVDS驱动移植与Android显示适配实战

1. 项目背景与LT8619c芯片定位

最近在基于NXP i.MX8MQ平台做Android 10的BSP适配，其中一个核心任务是把一颗HDMI转LVDS的桥接芯片——LT8619c的I2C驱动给移植上去。这活儿听起来就是改改设备树、调调驱动，但真干起来，里头的门道和坑一点不少。LT8619c这颗芯片在车载中控、工业显示这些领域用得挺多，主要就是负责把主控SoC输出的HDMI信号，转换成大屏需要的LVDS信号，同时还能通过I2C总线进行色彩、分辨率、时序等一堆参数的精细配置。在Android系统里，这块通常归到Display HAL层下面管，驱动本身不复杂，但让它在一个全新的硬件平台上稳定跑起来，尤其是配合Android复杂的显示框架，就得把内核驱动、设备树、HAL层乃至Framework层的调用链路都捋顺了。

我这次移植的目标平台是NXP的i.MX8MQ，CPU性能足够，显示子系统也挺强大。但原厂BSP里默认的显示输出可能是MIPI-DSI或者直接是LVDS，并没有LT8619c的现成配置。所以，整个移植过程其实就是一场“牵线搭桥”的工作：在内核里为这颗芯片准备好“座位”（设备节点）和“沟通方式”（驱动），并确保Android上层能通过标准的接口找到它、控制它。整个过程会涉及到Linux内核的I2C子系统、设备树（Device Tree）的编写、以及Android硬件抽象层（HAL）的适配。下面我就把这次移植中关键的步骤、遇到的坑以及最终的解决方案，掰开揉碎了讲清楚。

2. 内核层驱动移植：从源码到设备树

驱动移植的第一步，肯定是搞定内核部分。LT8619c的驱动，本质上是一个标准的I2C客户端（client）驱动。

2.1 驱动源码获取与初步审查

首先得找到驱动源码。通常芯片原厂（比如龙迅半导体）会提供一个Linux内核驱动模块，可能是一个独立的.c文件加一个.h头文件，或者是一个已经打好补丁的内核分支。我拿到的是一个名为lt8619c.c的驱动文件。拿到源码先别急着往里塞，第一件事是通读一遍，重点看几个地方：

1. 驱动兼容性列表（of_match_table）：这是驱动和设备树绑定的关键。代码里肯定会有一个struct of_device_id数组，里面包含类似{ .compatible = “lontium,lt8619c” }的条目。这个“lontium,lt8619c”字符串就是我们在设备树里要写的compatible属性，必须一字不差。
2. I2C设备ID表（i2c_device_id）：用于非设备树（纯靠i2c_board_info）的旧式匹配，现在基本以设备树为主，但这个表通常也得有，里面会有像{ “lt8619c”, 0 }这样的条目。
3. Probe函数：这是驱动的入口函数。要看清楚它在probe里都干了啥：是不是注册了一个i2c_client？有没有创建字符设备或者sysfs节点？最关键的是，它如何控制芯片？是仅仅通过I2C读写寄存器，还是需要操作额外的GPIO（比如复位脚、使能脚）？
4. 电源管理：有没有用到regulator（稳压器）？suspend和resume函数里是怎么处理芯片状态的？这对Android系统的休眠唤醒至关重要。

我手里的这个驱动，probe函数主要做了三件事：解析设备树获取配置（比如复位GPIO号、I2C从地址），申请并控制复位GPIO，最后通过I2C向LT8619c写入一系列初始化寄存器序列（通常是一个长长的数组，里面是{寄存器地址， 值}对）。这很典型。

2.2 设备树（DTS）节点编写

这是移植的核心环节，也是最容易出错的地方。我们需要在i.MX8MQ的平台设备树文件（比如imx8mq-evk.dts或你自定义的板级DTS文件）里，添加LT8619c的节点。

首先，要确定LT8619c挂载在哪个I2C总线上。i.MX8MQ有好几个I2C控制器（I2C1, I2C2, I2C3…）。需要查看硬件原理图，确认LT8619c的I2C_SCL和I2C_SDA线连接到了SoC的哪两个引脚，然后根据引脚复用关系找到对应的I2C总线。假设它接在I2C2上。

其次，要确定芯片的I2C从地址。LT8619c的地址通常由硬件引脚（ADDR）的上拉或下拉决定，原理图上会标明，常见的是0x64（7位地址）。在设备树里，reg属性就填这个地址。

最后，需要处理控制引脚，主要是复位（RESET）和可能有的电源使能（PWR_EN）或中断（INT）引脚。这些引脚需要配置为GPIO功能。

下面是一个设备树节点的示例，我把它放在&i2c2节点下：

&i2c2 { clock-frequency = <100000>; // I2C总线速率，100kHz通常够用 pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c2>; // 引用I2C2的引脚复用配置 status = "okay"; lt8619c: lt8619c@64 { compatible = "lontium,lt8619c"; // 必须与驱动中的of_match_table一致 reg = <0x64>; // I2C从设备地址 pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lt8619c>; // 专门为LT8619c控制引脚定义的复用组 // 复位GPIO，低电平有效 reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; // 电源使能GPIO，高电平有效（如果有） // enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; // 供电稳压器引用（如果有） // vcc-supply = <&reg_3v3>; // 芯片内部配置，可能通过属性传递，或在驱动里硬编码 lontium,input-format = "rgb"; // 假设输入格式 lontium,output-format = "lvds"; // 输出格式 lontium,data-lane-count = <4>; // LVDS数据通道数 // 显示时序参数，这些有时会在驱动里计算，但也可以在这里预定义 display-timings { native-mode = <&timing0>; timing0: timing0 { clock-frequency = <74250000>; // 像素时钟，74.25MHz对应1080p60 hactive = <1920>; vactive = <1080>; hfront-porch = <88>; hsync-len = <44>; hback-porch = <148>; vfront-porch = <4>; vsync-len = <5>; vback-porch = <36>; hsync-active = <1>; // 高电平有效 vsync-active = <1>; // 高电平有效 de-active = <1>; // 数据使能高有效 pixelclk-active = <0>; // 像素时钟下降沿采样 }; }; }; };

同时，必须在引脚控制器（pinctrl）部分定义用到的GPIO。在&iomuxc节点下添加：

pinctrl_lt8619c: lt8619cgrp { fsl,pins = < MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x19 /* RESET */ // MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x19 /* PWR_EN */ >; };

这里的0x19是引脚配置字，包含了上下拉、驱动强度、速率等，需要参考i.MX8MQ的参考手册和现有板级DTS来设置，不能乱写。

注意：设备树里的display-timings节点非常关键，但它描述的是LT8619c输出给LCD屏的时序。而LT8619c输入的HDMI时序，是由主控SoC（i.MX8MQ）的显示控制器（如DCSS或LCDIF）产生的。这两组时序必须匹配，或者驱动能在芯片内部完成转换。通常，我们更关注输出时序，因为它直接关系到屏幕能否点亮。输入时序则在配置SoC的显示输出时设置。

2.3 驱动集成与内核配置

有了设备树，接下来要把驱动源码集成到内核编译体系中。

1. 放置源码：将lt8619c.c和lt8619c.h放到内核源码的合适目录，比如drivers/gpu/drm/bridge/（因为它是一个显示桥接芯片）或者drivers/misc/。我选择放在drivers/gpu/drm/bridge/，这更符合其功能分类。
2. 修改Kconfig：在所在目录的Kconfig文件中添加配置选项。例如在drivers/gpu/drm/bridge/Kconfig里添加：

   config DRM_LONTIUM_LT8619C tristate "Lontium LT8619c HDMI to LVDS bridge" depends on DRM && I2C select DRM_KMS_HELPER select DRM_PANEL_BRIDGE help Driver for Lontium LT8619c HDMI to LVDS converter.

3. 修改Makefile：在对应目录的Makefile中添加编译条目：obj-$(CONFIG_DRM_LONTIUM_LT8619C) += lt8619c.o
4. 配置内核：执行make menuconfig，在图形界面中找到Device Drivers -> Graphics support -> Display Interface Bridges -> <M> Lontium LT8619c HDMI to LVDS bridge，将其编译为模块（M）或直接内置（*）。建议先选M，方便调试。

编译内核和模块后，将新的设备树Blob（.dtb文件）和驱动模块（.ko文件）烧录到设备。

3. 系统启动与驱动加载调试

烧录完新镜像，上电启动，这才是“实战”的开始。你需要通过串口控制台观察内核日志。

3.1 检查设备树解析与Probe

首先看驱动是否被正确匹配和加载。在串口日志中搜索“lt8619c”：

[ 2.345678] lt8619c 2-0064: probing LT8619c HDMI to LVDS bridge [ 2.345690] lt8619c 2-0064: Reset GPIO: 456 [ 2.345700] lt8619c 2-0064: Found initialization sequence, 120 entries [ 2.456789] lt8619c 2-0064: LT8619c initialized successfully.

如果看到类似的成功信息，恭喜你，设备树匹配和驱动probe都成功了。2-0064表示I2C总线2（适配器编号2），从地址0x64。

如果没看到，可能的问题有：

• 兼容字符串不匹配：检查设备树compatible属性和驱动of_match_table是否完全一致，包括大小写和标点。
• I2C总线不对：确认设备树节点放在了正确的&i2cX节点下。可以用命令i2cdetect -l列出所有I2C适配器，再用i2cdetect -y X（X为适配器号）扫描该总线，看能否看到地址0x64的设备。
• 引脚复用冲突：检查pinctrl设置是否正确，该引脚是否被其他功能占用。查看/sys/kernel/debug/pinctrl/pinctrl-handles或/sys/kernel/debug/gpio可以帮助诊断。
• 驱动未编译：确认内核配置已选中该驱动，并已编译进镜像或模块已正确加载（lsmod | grep lt8619c）。

3.2 I2C通信故障排查

驱动probe时，最常卡住的地方就是I2C读写初始化序列。如果日志停在“probing”之后没有成功消息，或者直接报I2C通信错误，就需要排查。

1. 硬件检查：用示波器或逻辑分析仪抓取I2C总线的SCL和SDA波形，是最直接的方法。看是否有起始信号、地址应答、数据波形。
2. 软件调试：
   • 在驱动源码的probe函数开始和第一个I2C操作前添加dev_info或pr_debug打印，确认执行流。
   • 可以临时修改驱动，将初始化序列的长度减少到1-2条最简单的寄存器写入命令，排除因某条特定命令导致芯片无应答的可能。
   • 检查I2C从地址。有时芯片的7位地址需要左移一位（addr << 1）作为读写标志，但标准Linux I2C驱动框架会处理这个，通常设备树里写7位地址即可。但有些原厂驱动可能自己处理，需要看驱动源码的具体实现。
   • 检查电源和复位时序。LT8619c可能对电源上电顺序和复位脉冲宽度有要求。确保在驱动probe之前，芯片的供电（包括核心电和IO电）已经稳定，并且复位引脚处于无效状态（根据硬件设计可能是高电平或低电平）。复位操作应该在供电稳定后，进行I2C通信前完成。驱动里的复位逻辑通常是：拉低复位脚 -> 延时（几毫秒）-> 拉高复位脚 -> 延时（几十毫秒等待芯片内部初始化）。

3.3 与Display框架的集成

LT8619c作为一个显示桥接芯片，在现代Linux DRM（Direct Rendering Manager）框架下，它应该被注册为一个drm_bridge。检查驱动源码，看它在probe的最后是否调用了drm_bridge_add或类似的函数。

成功注册为bridge后，它需要被连接到SoC的显示输出端口（如HDMI TX或DP）和LVDS面板（或panel）之间。这个连接关系也是在设备树中描述的。一个更完整的显示链路设备树可能像这样：

/ { ... lvds_panel: panel { compatible = "panel-lvds"; // 假设的LVDS面板通用驱动 >