RK3566 HDMI输入调试实战：从驱动到应用层的避坑手册

当你在RK3566平台上调试HDMI输入功能时，是否遇到过这样的场景：按照官方文档一步步配置，却发现HDMI信号源拔插无反应，或者分辨率切换失败，APK无法正确识别设备？这些问题往往不是配置流程的错误，而是隐藏在驱动和应用层交互中的"暗坑"。本文将深入这些技术细节，分享一套经过实战验证的调试方法论。

1. HDMI输入框架的底层逻辑与常见误区

RK3566平台的HDMI输入实现依赖于外接转接芯片（如LT6911UXC），这种架构带来了独特的调试挑战。与原生HDMI接收不同，转接方案将HDMI信号转换为MIPI-CSI或BT1120格式，通过V4L2框架呈现为类Camera设备。这种设计虽然复用现有框架，但也引入了几个关键差异点：

• 数据流特殊性：转接芯片通常直接输出YUV422格式，绕过了ISP的3A处理流程。这意味着传统的Camera调试方法可能不完全适用。
• 中断处理复杂性：相比标准Camera，HDMI输入需要额外处理拔插检测和分辨率切换两种中断，这是大多数问题的根源。
• 框架适配陷阱：V4L2的Media Controller拓扑结构在RK3566上比传统平台更复杂，错误的链路配置会导致数据流中断。

提示：使用media-ctl -p命令验证拓扑结构时，确保从转接芯片到VICAP的整个链路显示为"enabled"状态，任何"disabled"节点都可能是问题所在。

一个典型的错误认知是认为HDMI输入应该像USB Camera那样即插即用。实际上，RK3566的方案需要驱动和应用层的紧密配合：

c复制// 典型的中断处理函数结构
static irqreturn_t plugin_detect_irq_handler(int irq, void *dev_id)
{
    struct lt6911uxc *lt6911 = dev_id;
    bool plugin = gpio_get_value(lt6911->plugin_det_gpio);
    
    // 状态变化时才上报
    if (plugin != lt6911->plugin) {
        lt6911->plugin = plugin;
        v4l2_subdev_notify(&lt6911->subdev, LT6911_NOTIFY_PLUGIN, &plugin);
    }
    return IRQ_HANDLED;
}

这段代码展示了拔插检测中断的基本处理逻辑，但实际调试中常见三个陷阱：

1. GPIO极性配置错误（GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH混淆）
2. 未正确处理消抖（导致误触发）
3. 通知机制未正确挂接（应用层收不到事件）

2. 驱动层调试：从DTS配置到中断处理

驱动层是HDMI输入功能的基础，也是问题最集中的区域。以LT6911UXC芯片为例，我们需要特别关注以下几个关键环节：

2.1 DTS配置的魔鬼细节

DTS配置错误是导致HDMI输入无法工作的首要原因。以下是一个经过验证的配置模板，重点注意标粗的参数：

dts复制&i2c3 {
    lt6911uxc: lt6911uxc@2b {
        interrupt-parent = <&gpio4>;
        interrupt