4. Linux内核HDMI驱动框架：DRM子系统、KMS架构、I2C/DDC通信、EDID读取流程

好，咱们进入正题。这一章我打算聊聊Linux内核里HDMI驱动的核心骨架。说白了，就是DRM子系统、KMS架构、I2C/DDC通信，还有EDID读取这一整套流程。你想想看，一个HDMI接口要正常工作，背后得有多少软件栈在支撑？我当年第一次调通HDMI输出时，看着屏幕上出现画面，那种感觉——嗯，就像打通了任督二脉。

4.1 DRM子系统：显示输出的总管家

DRM，全称Direct Rendering Manager，直接渲染管理器。它最早是为图形加速设计的，后来慢慢演变成了显示输出的核心框架。我个人习惯把DRM理解成「显示设备的总线矩阵」——它管理着GPU、显示控制器、编码器、连接器这些硬件资源。

在DRM的世界里，有几个核心对象你必须搞明白：

• DRM Device：代表整个显示设备，通常是/dev/dri/card0
• CRTC：显示控制器，负责扫描输出和时序生成
• Encoder：编码器，把像素数据转换成特定接口信号（比如TMDS）
• Connector：连接器，代表物理接口（HDMI、DP、VGA等）
• Plane：图层，用于叠加显示内容

我在项目中遇到过一个问题：某个嵌入式平台上的HDMI输出死活没信号。查了半天，发现是DRM设备注册时，connector和encoder的匹配关系没配置对。你想想看，连接器找不到对应的编码器，信号怎么可能出去？

4.2 KMS架构：内核模式的显示管理

KMS，Kernel Mode-Setting，内核模式设置。它和DRM是什么关系？我打个比方：DRM是房子的框架，KMS就是里面的水电管线。KMS负责在内核空间完成显示模式的配置，包括分辨率、刷新率、色彩深度这些参数。

为什么要放在内核里做？早期Linux的显示模式设置是在用户空间完成的，每次切换分辨率都要经过一堆ioctl调用，效率低不说，还容易出问题。KMS把这些操作下沉到内核，说白了就是为了性能和稳定性。

KMS的核心数据结构是drm_display_mode，它描述了一个显示模式的所有时序参数：

struct drm_display_mode {
    // 时钟频率（Hz）
    int clock;
    // 水平方向参数
    int hdisplay, hsync_start, hsync_end, htotal;
    // 垂直方向参数
    int vdisplay, vsync_start, vsync_end, vtotal;
    // 同步信号极性
    bool flags;
    // 其他参数...
};

我曾经调试过一个4K@60Hz的HDMI输出问题。显示器一直报「无信号」，我用示波器量TMDS时钟，发现频率不对。后来查KMS代码，发现是clock字段的单位搞错了——驱动里传的是kHz，但KMS期望的是Hz。这种低级错误，嗯，谁还没犯过呢？

4.3 I2C/DDC通信：与显示器对话的桥梁

HDMI接口里有个隐藏的通道——DDC（Display Data Channel）。它基于I2C协议，专门用来和显示器「聊天」。你想想看，显卡怎么知道显示器支持什么分辨率？怎么知道它是不是HDMI 2.0？全靠DDC这条线。

DDC的物理层就是I2C，地址通常是0x50（写）和0x51（读）。在Linux内核里，DRM框架会自动为每个HDMI connector创建一个I2C适配器。驱动开发者只需要调用drm_get_edid()，剩下的I2C通信细节都由框架搞定。

但这里有个坑：I2C总线的时序要求很严格。我记得有一次，某个板子的HDMI输出时好时坏，最后发现是I2C的上拉电阻值不对，导致信号上升沿太慢。嗯，硬件工程师和软件工程师互相甩锅的场景，我见得太多了。

// 典型的DDC I2C通信流程
static int hdmi_ddc_read(struct i2c_adapter *adapter,
                         unsigned char *buf, int len)
{
    struct i2c_msg msg[2];
    // 先发送读命令
    msg[0].addr = 0x50;
    msg[0].flags = 0;
    msg[0].len = 1;
    msg[0].buf = &offset;
    // 再读取数据
    msg[1].addr = 0x50;
    msg[1].flags = I2C_M_RD;
    msg[1].len = len;
    msg[1].buf = buf;
    return i2c_transfer(adapter, msg, 2);
}

4.4 EDID读取流程：显示器的身份证

EDID，Extended Display Identification Data，扩展显示识别数据。它就像显示器的身份证，里面包含了厂商信息、支持的分辨率、色彩空间、音频能力等等。HDMI驱动启动时，第一件事就是通过DDC读取EDID。

EDID的结构是128字节的块，现代显示器通常有多个块（EDID 1.4支持最多4个块）。读取流程大致如下：

1. 通过DDC向显示器发送读取请求，地址0x50
2. 读取前128字节（块0），解析基本信息
3. 检查是否有扩展块（块1、2、3）
4. 如果有，继续读取后续块
5. 解析所有EDID数据，生成显示模式列表

在Linux内核里，这个过程被封装得很漂亮。你只需要调用drm_get_edid()，它就会自动完成所有I2C通信和解析工作。但作为驱动开发者，我建议你还是理解一下底层逻辑——毕竟出了问题还得自己查。

// 内核中EDID读取的核心路径
struct edid *drm_get_edid(struct drm_connector *connector,
                          struct i2c_adapter *adapter)
{
    struct edid *edid;
    // 读取块0
    edid = drm_do_get_edid(connector, adapter, 0);
    if (!edid)
        return NULL;
    // 检查扩展块
    if (edid->extensions > 0) {
        // 读取扩展块并合并
        edid = drm_do_get_edid_block(connector, adapter, edid, 1);
    }
    return edid;
}

我遇到过最奇葩的EDID问题是什么？某款廉价显示器的EDID里，分辨率列表居然包含了3840x2160@30Hz，但实际硬件只支持到1080p。结果系统自动选择了4K模式，画面一片漆黑。嗯，从那以后我养成了一个习惯：读取EDID后，一定要用drm_edid_is_valid()做校验。

4.5 整体流程串联

好了，我们把前面讲的串起来。一个完整的HDMI输出初始化流程是这样的：

1. DRM设备注册，创建connector、encoder、CRTC等对象
2. connector初始化时，通过DDC读取EDID
3. 解析EDID，生成支持的分辨率列表
4. 用户空间通过KMS接口设置显示模式
5. CRTC根据模式参数生成时序信号
6. encoder将像素数据编码为TMDS信号
7. 信号通过HDMI线缆传输到显示器

你想想看，这一整套流程，从软件到硬件，从内核到用户空间，环环相扣。任何一个环节出问题，画面就出不来。我刚开始做HDMI驱动时，总觉得不就是输出个画面吗？后来踩的坑多了，才明白这里面门道有多深。

这张图把整个流程串起来了。从上到下，从DRM到KMS，再到I2C/DDC，最后到EDID读取。每一层都依赖下一层提供的服务。我建议你在实际调试时，也按照这个顺序排查问题——先看EDID读没读到，再看KMS模式设置对不对，最后检查DRM对象有没有正确注册。

好了，这一章的内容就到这里。HDMI驱动的核心框架，说白了就是DRM + KMS + I2C/DDC + EDID这四块。你只要把这四块搞明白，大部分HDMI相关的问题都能迎刃而解。嗯，下一章我们聊聊实际项目中的调试方法和常见问题，到时候我会分享更多实战经验。

可可精品资料库