4. Media Controller 框架：Pipeline 抽象与 Entity/Links 管理
在复杂 Camera 系统中，尤其是 ISP（图像信号处理器）内部包含多个硬件处理模块（如 CSI 接收、RAW 去噪、Bayer 去马赛克、色彩校正、缩放、统计引擎等），传统的 V4L2 单一视频设备节点已无法清晰描述模块间的数据流拓扑。Media Controller（MC）框架应运而生，它将硬件内部的数据通路抽象为 Pipeline（流水线），通过 Entity（实体） 和 Link（连接） 的图结构，实现用户空间对硬件数据路径的精确控制。
4.1 核心概念：Entity、Pad、Link
Media Controller 框架的核心三要素构成了 Pipeline 的图论基础：
| 概念 | 符号 | 说明 | 典型实例 |
|---|---|---|---|
| Entity（实体） | 节点 | 代表一个硬件模块或软件 subdev，拥有唯一名称和 ID | imx219 6-0010（sensor）、rkisp-isp-subdev |
| Pad（接口） | 端口 | Entity 上的数据输入/输出端口，分为 SINK（输入）和 SOURCE（输出） | Sensor 的 SOURCE pad 0；ISP 的 SINK pad 0 |
| Link（连接） | 边 | 连接两个 Pad，定义数据流方向；可被 enable/disable | Sensor SOURCE → ISP SINK |
关键认知： Entity 是“硬件能力”的抽象，Pad 是“数据接口”的抽象，Link 是“数据通路”的抽象。三者共同构成一个有向无环图（DAG），HAL 层通过遍历该图来配置完整的 Camera 数据流。
4.2 Pipeline 抽象：从物理拓扑到逻辑图
下图展示了一个典型 ISP 硬件内部 Pipeline 的 Media Controller 抽象模型。每个矩形代表一个 Entity，左侧为 SINK Pad，右侧为 SOURCE Pad，箭头表示数据流方向。
Pipeline 抽象价值： HAL 层不再需要硬编码每个硬件模块的寄存器地址和连接关系，而是通过
media-ctl 或 MEDIA_IOC_ENUM_LINKS ioctl 动态枚举图结构，实现平台无关的 Pipeline 配置。
4.3 Entity 与 Link 管理：用户空间操作接口
Media Controller 框架通过 /dev/media0 设备节点暴露给用户空间，HAL 层通过以下 ioctl 完成 Entity 和 Link 的管理：
4.3.1 核心 ioctl 列表
| ioctl | 功能 | 数据结构 |
|---|---|---|
MEDIA_IOC_DEVICE_INFO |
获取 Media 设备信息（驱动名、模型名） | struct media_device_info |
MEDIA_IOC_ENUM_ENTITIES |
枚举所有 Entity（ID、名称、类型、Pad 数量） | struct media_entity_desc |
MEDIA_IOC_ENUM_LINKS |
枚举指定 Entity 的所有 Link（源/宿 Pad、标志位） | struct media_links_enum |
MEDIA_IOC_SETUP_LINK |
设置 Link 的启用/禁用状态 | struct media_link_desc |
4.3.2 典型 Pipeline 配置流程（HAL 侧）
- 打开 Media 设备：
open("/dev/media0", O_RDWR) - 获取设备信息：
MEDIA_IOC_DEVICE_INFO，确认驱动匹配。 - 枚举所有 Entity： 循环调用
MEDIA_IOC_ENUM_ENTITIES，构建 Entity 列表。 - 枚举 Link 拓扑： 对每个 Entity 调用
MEDIA_IOC_ENUM_LINKS，构建有向图。 - 配置数据通路： 根据 Camera 配置（如分辨率、格式），选择正确的 Entity 路径，调用
MEDIA_IOC_SETUP_LINK启用必要 Link，禁用无关 Link。 - 配置 subdev 格式： 通过 V4L2 subdev ioctl（
VIDIOC_SUBDEV_S_FMT）设置每个 Entity 的 Pad 格式。 - 启动视频流： 通过 Video Node（
/dev/video0）调用VIDIOC_STREAMON。
常见陷阱： 部分 SoC 的 ISP Pipeline 存在“虚拟 Entity”（如
rockchip-mipi-dphy-rx），它们不处理数据，仅用于拓扑约束。HAL 在枚举时必须跳过或特殊处理这些 Entity，否则可能导致 Link 配置失败。
4.4 Link 标志位与数据流控制
每个 Link 携带一组标志位，控制数据流的行为：
| 标志位 | 值 | 含义 | HAL 使用场景 |
|---|---|---|---|
MEDIA_LNK_FL_ENABLED |
0x0001 | Link 已启用，数据可流通 | 正常预览/拍照时置位 |
MEDIA_LNK_FL_IMMUTABLE |
0x0002 | Link 不可更改（硬件固定连接） | HAL 读取后跳过配置 |
MEDIA_LNK_FL_DYNAMIC |
0x0004 | Link 可在运行时动态切换 | 多 Camera 复用 ISP 时切换源 |
4.5 实战：HAL 与 Kernel 的 Link 对齐策略
在 HAL 与 Kernel 的接口对齐中，Media Controller 是最容易产生分歧的环节。以下策略可确保双方对 Pipeline 的理解一致：
- 策略一：静态拓扑验证 —— Kernel 在 probe 阶段通过
media_create_pad_link()建立默认 Link，HAL 在初始化时枚举所有 Link，与预定义的拓扑表比对，发现不匹配立即上报错误。 - 策略二：动态 Link 审计 —— 每次
MEDIA_IOC_SETUP_LINK调用后，HAL 回读 Link 状态，确认标志位与预期一致。Kernel 侧在media_entity_setup_link()中增加日志输出，便于调试。 - 策略三：Pipeline 快照 —— 在关键操作（如 start streaming）前后，HAL 通过
MEDIA_IOC_ENUM_LINKS导出完整拓扑快照，用于问题定位。
对齐契约示例： 假设 HAL 期望 Sensor → CSI → ISP → Video 的路径，但 Kernel 驱动因硬件复用将 CSI 直接连接到另一个 ISP 实例。HAL 通过枚举发现 Link 不匹配后，应拒绝启动并返回
-EINVAL，而不是盲目配置导致系统挂死。
4.6 小结
Media Controller 框架通过 Entity/Pad/Link 的图抽象，将复杂的 Camera 硬件 Pipeline 转化为用户空间可枚举、可配置的拓扑结构。HAL 层需要掌握以下核心能力：
- 使用
MEDIA_IOC_ENUM_ENTITIES和MEDIA_IOC_ENUM_LINKS动态发现硬件拓扑。 - 通过
MEDIA_IOC_SETUP_LINK精确控制数据通路。 - 理解 Link 标志位（IMMUTABLE/DYNAMIC）对配置策略的影响。
- 建立 HAL 与 Kernel 之间的拓扑对齐验证机制，避免因驱动变更导致的 Pipeline 断裂。