struct my_bridge {
    struct drm_bridge base;
    struct drm_connector connector; // 这个是为了抄 HDMI 驱动加的
    struct drm_bridge *panel_bridge; // 这个是为了抄 Panel 驱动加的
    struct drm_bridge *next_bridge;  // 这个是为了抄其他 Bridge 驱动加的
    // ... 
};

【直觉写法：大杂烩】
+-------------------------------------------------------+
| struct my_bridge {                                    |
|   struct drm_bridge base;                             |
|   struct drm_connector connector; // 多余！            |
|   struct drm_bridge *next;        // 冗余！            |
|   ...                                                 |
| }                                                     |
+-------------------------------------------------------+
   问题：角色不清，逻辑冲突，注册了不该注册的资源。


【正确做法：按需定岗】

场景 A (中间节点):
   SoC -> [Bridge A] -> [Bridge B] -> ...
   结构体：bridge + *next_bridge

场景 B (终点接口):
   SoC -> [Bridge] -> HDMI 母座
   结构体：bridge + connector

场景 C (驱动面板):
   SoC -> [Bridge] -> 固定屏幕
   结构体：bridge + *panel_bridge

场景 D (复杂):
   SoC -> [Bridge] -> HDMI 母座 (且内部还有逻辑子链路)
   结构体：bridge + connector + *next_bridge

[Probe 阶段]
   |
   v
分析设备树 -> 判断硬件拓扑
   |
   +---> 后面是 HDMI 接口? -> 封装 connector
   |
   +---> 后面是另一个 Bridge? -> 定义 *next_bridge
   |
   +---> 后面是固定屏幕? -> 定义 *panel_bridge
   |
   v
[Attach 阶段]
   |
   v
如果定义了 connector -> drm_connector_init() (创建终点)
如果定义了 *next -> drm_bridge_attach() (连接下级)
如果定义了 *panel -> devm_drm_panel_bridge_add() (包装屏幕)

/*
 * 场景：一个极其简单的 Level Shifter（电平转换器）
 * 特点：透明传输，无需关心后面是谁
 */
struct simple_shifter {
    struct drm_bridge bridge; // 本体
    struct gpio_desc *enable_gpio;
};

static const struct drm_bridge_funcs shifter_funcs = {
    .enable = shifter_enable,
    // ...
};

/*
 * 场景：RGB to LVDS Converter
 * 特点：需要把数据传给下一个 Bridge
 */
struct lvds_converter {
    struct drm_bridge bridge;      // 内嵌内核对象
    struct drm_bridge *next_bridge; // 指向链路中的下一个 bridge
    struct i2c_client *client;
};

// 辅助宏
#define to_lvds_converter(b) container_of(b, struct lvds_converter, bridge)

static int lvds_attach(struct drm_bridge *bridge,
                       enum drm_bridge_attach_flags flags)
{
    struct lvds_converter *lvds = to_lvds_converter(bridge);

    // 核心：调用内核函数挂载下一级，返回下一级 bridge 的指针
    // 注意：这里传入 flags，如果下级需要创建 connector，由下级决定
    lvds->next_bridge = drm_bridge_attach(bridge->encoder, 
                                          lvds->next_bridge, 
                                          bridge, flags);
    if (IS_ERR(lvds->next_bridge))
        return PTR_ERR(lvds->next_bridge);

    return 0;
}

为什么这样设计？
保存 next_bridge 指针是为了在 enable、mode_set 等回调中，通过 drm_bridge_chain_xxx 系列函数手动通知下级设备，或者仅仅是确认挂载成功。

3. 形式三：终点站（drm_bridge + drm_connector）

场景：HDMI 发送器，输出到母座，需要处理热插拔（HPD）和 EDID。

/*
 * 场景：HDMI Transmitter
 * 特点：链路终点，需要创建 Connector
 */
struct hdmi_transmitter {
    struct drm_bridge bridge;
    struct drm_connector connector; // 自己管理 Connector
    struct i2c_client *client;
};

#define to_hdmi_transmitter(b) container_of(b, struct hdmi_transmitter, bridge)

static int hdmi_attach(struct drm_bridge *bridge,
                       enum drm_bridge_attach_flags flags)
{
    struct hdmi_transmitter *hdmi = to_hdmi_transmitter(bridge);
    int ret;

    // 如果内核没有禁止创建 Connector (通常 HDMI 驱动必须创建)
    if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
        // 1. 初始化 Connector
        ret = drm_connector_init(bridge->dev, &hdmi->connector,
                                 &hdmi_connector_funcs,
                                 DRM_MODE_CONNECTOR_HDMIA);
        if (ret)
            return ret;

        // 2. 将 Connector 挂在 Encoder 上，并关联当前的 Bridge
        drm_connector_attach_encoder(&hdmi->connector, bridge->encoder);
    }

    return 0;
}

// Connector 的操作函数，用于 HPD 和 EDID
static int hdmi_get_modes(struct drm_connector *connector) {
    // 读取 EDID ...
    return 0;
}

为什么这样设计？
HDMI 接口对应物理上的“接口”而非“屏”。用户空间需要通过 Connector 来获知“屏幕插上了吗？”、“支持什么分辨率？”。所以驱动必须封装 Connector。

4. 形式四：面板管家（drm_bridge + panel_bridge）

场景：Bridge 后面直接挂了一块固定屏幕（Panel）。这是目前最主流的做法。

/*
 * 场景：DPI to MIPI Bridge + 固定屏
 * 特点：利用 panel_bridge 将 Panel 纳入 Bridge 链路
 */
struct dpi_to_mipi {
    struct drm_bridge bridge;
    struct drm_bridge *panel_bridge; // 用于包装 Panel
    struct mipi_dsi_host *host;
};

static int dpi_to_mipi_probe(struct i2c_client *client)
{
    struct dpi_to_mipi *ctx;
    struct drm_panel *panel;

    ctx = devm_kzalloc(...);

    // 1. 获取设备树中引用的 Panel 节点
    ret = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0, &panel, NULL);
    if (ret)
        return ret;

    // 2. 关键：将 Panel 包装成一个 Bridge
    // 这个 panel_bridge 内部实现了 Panel 的时序控制
    ctx->panel_bridge = devm_drm_panel_bridge_add(&client->dev, panel);
    if (IS_ERR(ctx->panel_bridge))
        return PTR_ERR(ctx->panel_bridge);

    // 注册自己
    return devm_drm_bridge_add(&client->dev, &ctx->bridge);
}

static int dpi_to_mipi_attach(struct drm_bridge *bridge,
                              enum drm_bridge_attach_flags flags)
{
    struct dpi_to_mipi *ctx = to_ctx(bridge);

    // 3. 直接挂载 panel_bridge
    // 因为 panel_bridge 是内核标准的 bridge，这里逻辑就统一了
    return drm_bridge_attach(bridge->encoder, ctx->panel_bridge, bridge, flags);
}

为什么这样设计？
这是目前 Linux DRM 最推荐的“最佳实践”。把 Panel 包装成 Bridge 后，整个显示链路变成了清一色的 Bridge 链表。驱动不需要关心 Panel 的上下电细节，只需要把数据流传给 panel_bridge 即可。

5. 形式五：混合双打（drm_bridge + drm_connector + next_bridge）

场景：相对复杂的 Bridge 芯片。比如一个 HDMI 转 LVDS 芯片，它一方面需要一个 Connector 来接收 HDMI 输入（Input，这种叫 mux），或者它作为输出端创建 Connector，同时内部还有逻辑子链路需要管理。
更常见的例子：它是输出端（需要 Connector），同时它内部又集成了一个驱动逻辑，需要挂接下一级 Bridge。

/*
 * 场景：智能 HDMI 转换器
 * 特点：自己创建 Connector，同时后面还挂着下一级 Bridge
 */
struct smart_bridge {
    struct drm_bridge bridge;
    struct drm_connector connector; // 自己的 Connector
    struct drm_bridge *next_bridge; // 下级 Bridge
};

static int smart_attach(struct drm_bridge *bridge,
                        enum drm_bridge_attach_flags flags)
{
    struct smart_bridge *s = ...;

    // 1. 创建 Connector (自己的职责)
    if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
        drm_connector_init(..., &s->connector, ...);
    }

    // 2. 挂接下级 (转发职责)
    // 注意：下级通常不需要创建 Connector，因为我们已经有了
    s->next_bridge = drm_bridge_attach(bridge->encoder, s->next_bridge, 
                                       bridge, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
    return PTR_ERR_OR_ZERO(s->next_bridge);
}

2.5 再进一步：生产环境中的“坑”与“招”

在实际开发中，结构体定义只是第一步，怎么用才是关键。

1. DRM_BRIDGE_ATTACH_NO_CONNECTOR 标志位陷阱
这是最容易踩的坑。

• • 如果你实现的是 形式三（Connector）：一定要检查 flags。如果上层传了这个标志，说明上层（如 DRM Core 或 Writeback Connector）想自己管理 Connector，你就别创建了。
• • 如果你实现的是 形式四：调用 drm_bridge_attach 挂接 Panel Bridge 时，通常要手动加上这个标志，防止 Panel Bridge 内部再冒出一个 Connector 来。

2. 生命周期管理

• • bridge 和 connector 是内嵌的，随私有结构体一起分配（devm_kzalloc），一起释放。
• • next_bridge 和 panel_bridge 是借来的指针，指向内核其他地方的对象，不要尝试释放它们。

3. 调试技巧
在 attach 函数里打印一下关键信息，能帮你理清拓扑：

DRM_DEV_INFO(dev, "Attach: self=%p, next=%p, flags=0x%x\n", 
             &ctx->bridge, ctx->next_bridge, flags);

2.6 整体流程回顾

最后，我们用一张图把“结构体定义决策”串起来：

[开始编写 Bridge 驱动]
   |
   v
[硬件拓扑分析]
   |
   +---> 我是链路终点吗？(输出接口是 HDMI/DP 母座)
   |       |
   |       +--YES--> 结构体内嵌: drm_connector
   |       |
   |       +--NO---> 结构体不包含 connector
   |
   +---> 我后面有下级设备吗？
           |
           +--YES--> 下级是 Bridge? -> 定义 *next_bridge
           |         下级是 Panel? -> 定义 *panel_bridge (并通过 API 获取)
           |
           +--NO---> 只需要 drm_bridge
   |
   v
[编写 Probe]
   分配结构体 -> 初始化 bridge.funcs -> 处理 panel 指针
   |
   v
[编写 Attach]
   根据 flags 决定是否 init connector
   调用 drm_bridge_attach 连接下级

写在最后

Linux DRM Bridge 的私有结构体封装，本质上就是**“链路拓扑的 C 语言映射”**。

1. 1. 组合模式：通过内嵌对象和指针引用，C 语言完美模拟了复杂的硬件拓扑结构。
2. 2. 职责单一：不要贪多，根据硬件角色定义字段，Connector 管插拔，Bridge 管转换，Panel 管显示。
3. 3. 链式思维：Bridge 驱动的核心在于“传递”。定义 next_bridge 是为了把控制权传递下去，定义 connector 是为了终止链路并向上暴露接口。

所以，drm驱动的私有结构体定义，是根据硬件拓扑图来得，也可以说根据设备树定义来的，多定义过少定义，都会影响整个drm链路。如果没有定义好，也许跑Qt应用程序可以，但Weston可能会奔溃！