小白也能懂-HDMI linux驱动框架

大家好，我是快乐学习，开心分享的科技探索员 🎉

前两篇文章中，我们从物理层的TMDS编码聊到协议层的EDID/HDCP/CEC/HDR，把HDMI的「硬件原理」和「协议栈」基本拆解完了。

但作为嵌入式工程师，光懂协议还不够——当你拿到一块新板子，把HDMI线插上去，屏幕不亮怎么办？这就需要了解Linux下的HDMI驱动框架了。

这篇，我们就从Linux DRM/KMS架构讲起，深入HDMI驱动层的Connector、Encoder、PHY配置，再到HDCP驱动实现、音频通道配置，最后用modetest工具带你走一遍从黑屏到点亮的完整调试流程。

⚠️ 本文为「小白也能懂·HDMI」系列第③篇（最终篇），建议先阅读第①②篇。

一、Linux显示子系统架构：DRM/KMS

在Linux中，所有显示相关的驱动都统一在一个框架下——DRM（Direct Rendering Manager）。而负责「设置显示模式」的子系统，叫KMS（Kernel Mode Setting）。

1.1 DRM/KMS核心组件

理解HDMI驱动，首先要搞清楚DRM/KMS中的几个核心角色。可以把它们想象成一条「显示流水线」：

1、Plane（图层）：管理显示缓冲区，决定画面内容。包括主画面（Primary）、光标（Cursor）、覆盖层（Overlay）。

2、CRTC（时序控制器）：控制扫描时序、刷新率、像素时钟。每个CRTC对应一个独立的显示管道。

3、Encoder（编码器）：把CRTC的并行数字信号转换为串行信号，送到物理接口（HDMI/DP等）。

4、Bridge（桥接芯片）：可选的中间转换芯片，如HDMI转MIPI、LVDS转HDMI等。

5、Connector（连接器）：代表物理输出接口，管理热插拔（HPD）、EDID读取、HDCP状态。

▲ drm kms architecture

▲ 核心数据流：App → DRM ioctl → KMS原子提交 → CRTC(时序) → Encoder(编码) → Bridge(桥接) → Connector(输出) → PHY(物理层) → TMDS/FRL信号 → 显示器

1.2 原子提交（Atomic Commit）

现代DRM使用「原子提交」机制来统一管理硬件状态变更。所谓原子，就是所有配置（CRTC模式、Plane位置、Encoder使能等）要么全部生效，要么全部回滚，不会出现「画面改了一半」的情况。

drm_atomic_helper_check()// 校验所有配置是否合法

drm_atomic_helper_commit() // 原子提交，一次性应用到硬件

💡 原子提交大幅简化了驱动的状态管理逻辑，避免出现不一致的中间状态。

二、HDMI Connector驱动

Connector是HDMI驱动的「对外窗口」——它负责检测显示器插拔、读取EDID、管理HDCP状态，向上层报告连接器状态。

2.1 HPD热插拔检测

当HDMI线缆插入或拔出时，HPD（Hot Plug Detect）引脚的电平会发生变化。驱动通过GPIO中断来捕获这个事件，然后触发连接器的探测流程。

完整的HPD处理流程：

1、HDMI线缆插入 → HPD引脚电平变化（低→高）

2、GPIO中断触发 → 进入中断处理函数

3、调用 drm_helper_hpd_irq_event() → 调度输出探测

4、执行 connector->detect() 回调 → 返回连接状态

5、如果已连接，自动读取EDID并创建display_mode列表

▲ hdmi connector flow

⚠️ 如果HPD一直不触发，首先检查GPIO配置、中断注册、上拉电阻（通常10K-100K）。

2.2 EDID在驱动中的读取

内核通过DDC（I2C）通道读取显示器的EDID数据。关键函数调用链：

drm_get_edid(connector, adapter)// 读256字节EDID

→ i2c_transfer()// I2C读操作

→ Address 0x50, 读256字节// DDC设备地址

drm_edid_block_valid()// 校验EDID合法性

drm_do_add_edid_modes()// 解析并添加显示模式

关键调试命令：

cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode

# 或者用 hexdump 查看原始数据

hexdump -C /sys/class/drm/card0-HDMI-A-1/edid | head -20

2.3 Connector回调函数集

HDMI Connector通过 drm_connector_funcs 回调函数集与DRM核心交互：

三、HDMI Encoder与PHY配置

Encoder负责把CRTC输出的显示数据编码为HDMI协议所需的信号格式，PHY则负责把这些数字信号变成差分电信号发送出去。

3.1 时钟链路：从OSC到TMDS

HDMI的像素时钟是整个显示系统的「心跳」。时钟链路从振荡器（OSC）开始，经过PLL倍频、分频器调整，最终生成精确的像素时钟：

1、晶振（OSC）：通常27MHz基准时钟

2、PLL倍频：根据目标分辨率计算倍频系数N

3、分频器：分频系数M，生成精确像素时钟

4、TMDS字符时钟：像素时钟 × 10（8b/10b编码开销）

5、PHY串行时钟：决定差分信号的传输速率

▲ phy clock config

典型像素时钟：

⚠️ 像素时钟精度偏差需控制在 +/-0.5% 以内，否则显示器可能无法同步，表现为花屏或黑屏。

3.2 TMDS vs FRL模式

HDMI 2.0及以下使用TMDS模式，HDMI 2.1引入了全新的FRL（Fixed Rate Link）模式：

TMDS模式：（HDMI 2.0及以下）

● 3对数据 + 1对时钟 = 4对差分线

● 8b/10b编码，20%带宽开销

● 单通道最高6Gbps（HDMI 2.0）

● 差分摆幅约800mV

FRL模式：（HDMI 2.1）

● 3或4 Lane数据通道，无独立时钟线

● 16b/18b编码，约11%开销

● 单Lane最高12Gbps

● 内置FEC前向纠错（Reed-Solomon）

● 需CDR（Clock Data Recovery）从数据中恢复时钟

3.3 常见HDMI PHY驱动

四、HDCP在Linux中的实现

第②篇我们讲了HDCP的认证原理，这篇来看看它在Linux内核中是如何实现的。

4.1 内核HDCP框架

Linux内核提供了统一的HDCP框架，定义在 include/drm/drm_hdcp.h 中。核心数据结构是 drm_hdcp_state，维护HDCP的认证状态。

HDCP状态机有四个状态：

1、DRM_MODE_HDCP_OFF：HDCP未启用

2、DRM_MODE_HDCP_DESIRED：用户请求启用，等待认证

3、DRM_MODE_HDCP_UNDESIRED：用户主动关闭

4、DRM_MODE_HDCP_ENCRYPTED：认证成功，内容已加密

▲ hdcp driver arch

4.2 HDCP 2.2认证驱动流程

HDCP 2.2的认证流程比1.4复杂得多，但内核已经做了很好的封装：

1、AKE_Init：交换证书和主密钥（RX证书 + TX公钥）

2、AKE_Stored_Km：使用存储的密钥材料，验证接收端身份

3、LC_Init：本地校验完成，确认链路完整性

4、SKE_Send_Eks：交换会话密钥（Eks），开始加密传输

5、Repeater拓扑验证：如果是级联设备，验证整个拓扑结构

关键内核函数：

drm_hdcp2_enable_encryption()// 启用HDCP加密

drm_hdcp2_check_link()// 定期检查链路完整性

drm_hdcp2_verify_mst_topology()// 验证级联拓扑

4.3 HDCP调试

查看HDCP状态：

cat /sys/class/drm/card0-HDMI-A-1/properties/content_protection

dmesg关键日志：

[drm] hdcp: authentication failed (-EIO)# 认证失败

[drm] hdcp: authenticated successfully# 认证成功

[drm] hdcp: KSV list revocation check failed # 设备被撤销

⚠️ HDCP认证失败的排查顺序：1) 检查TX/RX版本匹配 2) 确认密钥已烧录 3) 检查SRM是否过期 4) 尝试直连排除中间设备

五、音频通道配置

HDMI不仅传视频，还能传音频。在Linux下，HDMI音频通过ALSA子系统 + DRM框架协作实现。

5.1 HDMI音频数据流

音频从应用层到HDMI输出的完整路径：

1、应用层播放器（如mpv/ffplay）通过ALSA接口输出PCM音频

2、ALSA声卡驱动将音频数据送入DMA/FIFO缓冲区

3、HDMI IP核从FIFO读取音频数据，打包到HDMI数据岛中

4、通过Audio InfoFrame告诉接收端音频格式参数

5、接收端根据InfoFrame解码音频数据

▲ audio subsystem

5.2 Audio InfoFrame配置

Audio InfoFrame是HDMI传递音频参数的「信封」，包含以下关键字段：

● 音频格式编码（LPCM / AC-3 / DTS / MPEG-AAC）

● 声道数（2ch / 4ch / 6ch / 8ch）

● 采样频率（32/44.1/48/88.2/96/176.4/192 kHz）

● 采样位深（16/20/24 bit）

● 声道分配映射（speaker allocation）

5.3 ARC与eARC

ARC（Audio Return Channel）让电视内置APP的音频通过HDMI线回传给Soundbar，省去了额外的光纤线。

5.4 音频常见问题

有画面无声音：检查Audio InfoFrame是否正确配置，确认TX端音频DMA已启用

ARC无声：确认电视端ARC已开启，HDMI线CEC线完好

声音断续：音频采样率与sink不匹配，尝试降至48kHz

声道错误：检查Audio InfoFrame的Channel Allocation映射

六、调试实战：从黑屏到点亮

终于到了实战环节！假设你拿到一块新板子，接上HDMI显示器，屏幕不亮。我们按照以下7步来排查。

▲ debug workflow

6.1 Step 1：确认HPD

dmesg | grep -i hpd

如果看不到任何HPD相关的日志，说明GPIO中断没有正确触发。检查：

● 设备树中HDMI HPD GPIO配置是否正确

● GPIO中断是否注册成功

● HPD引脚是否有上拉电阻（通常10K-100K）

6.2 Step 2：读取EDID

cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode

如果读不到EDID或数据全0，检查：

● DDC I2C引脚（Pin15/16）接线是否正确

● I2C设备地址0x50是否可访问

● 上拉电阻是否已添加（SCL/SDA各4.7K）

6.3 Step 3：检查CRTC

modetest -c

确认CRTC已绑定正确的display_mode（分辨率、刷新率）。如果mode列表为空，说明EDID解析有问题。

6.4 Step 4：Encoder Enable

dmesg | grep -i encoder

确认HDMI Encoder已经使能。如果没有encoder日志，可能是原子提交没有成功执行。

6.5 Step 5：PHY配置

检查PHY的PLL是否锁定，差分信号是否正常输出。

● 用示波器测量TMDS差分信号眼图

● 确认差分阻抗100 Ohm（偏差<10%）

● 确认PLL锁定状态寄存器

6.6 Step 6：HDCP认证

cat /sys/class/drm/card0-HDMI-A-1/properties/content_protection

如果显示「Desired」但无法变为「Enabled」，说明HDCP认证失败。参照第四章的排查思路。

6.7 Step 7：强制点亮测试

如果以上步骤都确认无误，可以用modetest强制点亮：

modetest -M -s HDMI-A-1@3840x2160

💡 modetest是DRM自带的测试工具，绕过用户空间显示服务器，直接操作内核DRM接口，是HDMI调试的「瑞士军刀」。

七、总结与进阶方向

三篇文章写下来，我们从物理层到协议层再到驱动层，把HDMI的「里里外外」拆了个遍。最后用一张速查表做个总结：

▲ knowledge summary

7.1 常见坑速查

7.2 系列回顾

第1篇基础原理篇：TMDS编码、8b/10b、版本演进、带宽计算、HDMI vs DP

第2篇协议与HDCP篇：EDID/DDC、HDCP认证、CEC+ARC+eARC、HDR色彩空间、InfoFrame

第3篇驱动框架篇：DRM/KMS架构、Connector+Encoder+PHY、HDCP驱动、音频子系统、modetest实战

结论：从物理层到协议层再到驱动层，三篇文章帮你建立了完整的HDMI知识体系。做HDMI相关的硬件选型、PCB设计、驱动开发时，希望这些内容能成为你的案头参考。

如果你觉得这个系列有帮助，欢迎点赞收藏，在评论区留下你的问题，我们下个系列见！👋