📚 课程目录第2章 V4L2框架基础

Linux内核Camera子系统原理与实战详解 - 第2节

2.1 V4L2 的历史演进

Video for Linux Two（V4L2）是 Linux 内核中视频设备驱动的标准框架，自 2002 年合并入主线内核以来，经历了多次重大重构。理解其历史有助于把握框架的设计哲学。

阶段	时间	关键变化
V4L（第一代）	1998–2002	仅支持模拟 TV 采集卡，缺乏扩展性，用户空间通过 `read/write` 直接操作设备
V4L2 初始版本	2002–2005	引入 `ioctl` 控制体系、流式 I/O（mmap）、设备能力查询，支持 USB 摄像头
V4L2 稳定期	2005–2012	增加 `v4l2_subdev` 子设备模型，分离传感器与 ISP 驱动，支持 Media Controller
V4L2 现代期	2012–至今	引入请求队列（Request API）、统计缓冲区（Statistics）、多平面格式（Multiplanar）

设计原则： V4L2 始终遵循“用户空间通过文件操作语义控制硬件”的 Unix 哲学。设备节点即文件，ioctl 即控制命令，mmap 即零拷贝数据通道。

2.2 核心数据结构全景

V4L2 框架围绕三个核心结构体组织：video_device、v4l2_device、v4l2_subdev。它们之间的关系构成了驱动层的骨架。

2.2.1 v4l2_device —— 顶层容器

v4l2_device 是 V4L2 驱动的根结构体，代表一个完整的 Camera 硬件实例。它负责管理所有子设备和视频节点。

struct v4l2_device {
    struct device *dev;              // 指向 struct device（Linux 设备模型）
    struct list_head subdevs;        // 已注册的子设备链表
    spinlock_t lock;                 // 内部锁
    char name[V4L2_DEVICE_NAME_SIZE]; // 设备名称
    void (*notify)(struct v4l2_subdev *sd, unsigned int notification, void *arg);
    // 子设备通知回调
};

  关键职责：
  作为驱动与 Linux 设备模型的桥梁，通过 dev 字段关联到 platform_device 或 i2c_client
维护子设备链表，支持子设备热插拔
提供 notify 回调，实现子设备到父设备的异步通信

2.2.2 video_device —— 用户空间接口

video_device 是用户空间看到的字符设备节点（/dev/video0、/dev/video1 等）。它封装了文件操作函数集和 V4L2 标准 ioctl 处理逻辑。

struct video_device {
    const struct v4l2_file_operations *fops; // 文件操作（open/release/ioctl/mmap/poll）
    struct v4l2_ioctl_ops *ioctl_ops;        // V4L2 标准 ioctl 实现
    struct device dev;                       // 内嵌字符设备
    struct v4l2_device *v4l2_dev;            // 所属顶层设备
    unsigned int index;                      // 设备节点编号
    char name[32];                           // 设备名称
    // 视频能力、格式、队列等
};

字段	作用	典型值/说明
`fops`	用户空间系统调用入口	`v4l2_open`、`v4l2_ioctl`、`v4l2_mmap`
`ioctl_ops`	V4L2 标准命令处理	`vidioc_querycap`、`vidioc_s_fmt`、`vidioc_reqbufs`
`v4l2_dev`	反向关联顶层设备	用于访问子设备和其他资源
`index`	设备节点编号	0 → `/dev/video0`

2.2.3 v4l2_subdev —— 子设备抽象

v4l2_subdev 是 V4L2 框架最具特色的设计之一。它将 Camera 管线中的独立硬件单元（传感器、ISP、编解码器、闪光灯）抽象为统一接口的子设备。

struct v4l2_subdev {
    struct v4l2_device *v4l2_dev;       // 所属顶层设备
    struct module *owner;               // 所属内核模块
    const struct v4l2_subdev_ops *ops;  // 子设备操作函数集
    struct v4l2_subdev_pad_config *config; // pad 配置
    struct media_entity entity;         // Media Controller 实体
    char name[V4L2_SUBDEV_NAME_SIZE];  // 子设备名称
    unsigned int flags;                 // 标志位
};

子设备操作函数集： v4l2_subdev_ops 包含多个子操作集，如 core（核心控制）、video（视频流）、pad（pad 操作）、sensor（传感器专用）等。驱动开发者只需实现硬件相关的回调。

2.3 设备节点与用户空间交互

V4L2 的用户空间交互完全遵循“一切皆文件”的 Unix 哲学。应用程序通过标准的文件操作与内核驱动通信。

2.3.1 设备节点创建流程

驱动初始化： 调用 v4l2_device_register() 注册顶层设备
子设备注册： 调用 v4l2_subdev_register() 注册传感器、ISP 等子设备
视频节点注册： 调用 video_register_device() 创建 /dev/videoX 节点
udev 通知： 内核通过 uevent 通知用户空间 udev，自动创建设备节点文件

2.3.2 关键 ioctl 命令

ioctl 命令	功能	用户空间调用示例
`VIDIOC_QUERYCAP`	查询设备能力（驱动名称、总线信息、支持类型）	`ioctl(fd, VIDIOC_QUERYCAP, &cap)`
`VIDIOC_ENUM_FMT`	枚举支持的像素格式	`ioctl(fd, VIDIOC_ENUM_FMT, &fmt)`
`VIDIOC_S_FMT`	设置采集格式（分辨率、像素格式）	`ioctl(fd, VIDIOC_S_FMT, &fmt)`
`VIDIOC_REQBUFS`	请求分配 DMA 缓冲区	`ioctl(fd, VIDIOC_REQBUFS, &req)`
`VIDIOC_QBUF`	将缓冲区加入驱动队列	`ioctl(fd, VIDIOC_QBUF, &buf)`
`VIDIOC_DQBUF`	从驱动队列取出已填充数据的缓冲区	`ioctl(fd, VIDIOC_DQBUF, &buf)`
`VIDIOC_STREAMON`	启动视频流	`ioctl(fd, VIDIOC_STREAMON, &type)`

2.3.3 缓冲区管理机制

V4L2 支持三种缓冲区交换模式，其中 mmap 模式是性能最优的零拷贝方案：

Read/Write 模式： 通过 read()/write() 系统调用拷贝数据，适合低带宽场景
MMAP 模式： 通过 mmap() 将内核 DMA 缓冲区映射到用户空间，实现零拷贝
User Pointer 模式： 用户空间提供缓冲区地址，驱动直接 DMA 写入（需要 IOMMU 支持）

常见陷阱： 在 MMAP 模式下，VIDIOC_REQBUFS 必须在 VIDIOC_S_FMT 之后调用，因为缓冲区大小取决于格式配置。另外，VIDIOC_STREAMON 前必须至少入队一个缓冲区。

2.4 本章小结

V4L2 框架通过三个核心数据结构构建了从硬件到用户空间的完整通道：

v4l2_device 作为顶层容器，管理设备生命周期和子设备
video_device 提供字符设备接口，承载所有用户空间交互
v4l2_subdev 抽象硬件子单元，实现模块化驱动设计

用户空间通过标准的文件操作（open/ioctl/mmap/poll）与驱动交互，其中 ioctl 命令集定义了完整的控制协议，mmap 模式实现了高效的零拷贝数据通道。理解这些基础结构是后续深入学习 Camera 管线配置、缓冲区管理和 Media Controller 框架的前提。