4、V4L2框架基础：Video for Linux 2核心数据结构、ioctl调用流程、buffer管理机制

好，咱们今天聊聊V4L2。说实话，这个框架是嵌入式视觉开发的基石。你想想看，高通8155上接的摄像头模组，最终都是通过V4L2来跟应用层打交道的。我当年刚接触这个框架时，也被那一堆结构体和ioctl搞得头大。但摸清楚套路后，你会发现它其实挺优雅的。

4.1 核心数据结构：V4L2的骨架

V4L2的核心数据结构，说白了就三个：video_device、v4l2_device和vb2_queue。它们之间的关系，我习惯用「三层架构」来理解。

第一层：v4l2_device —— 顶层容器

它代表一个V4L2设备实例。在8155平台上，每个ISP实例都会对应一个v4l2_device。我做过一个项目，需要同时驱动4路摄像头，那就得注册4个v4l2_device，每个独立管理自己的子设备。

第二层：video_device —— 用户看到的节点

这就是/dev/video0、/dev/video1这些。它负责把内核驱动跟用户空间的open()、ioctl()调用连接起来。每个video_device都要实现一个v4l2_file_operations结构体，里面填好你的回调函数。

第三层：vb2_queue —— 缓冲区管理核心

这是我最看重的部分。所有视频数据的流转，都靠它来调度。后面我会详细讲。

嗯，这里要注意：这三个结构体不是平级的。v4l2_device包含video_device，而video_device又关联着vb2_queue。我刚开始写驱动时，把它们的初始化顺序搞反了，结果内核直接panic。后来养成习惯：先初始化v4l2_device，再注册video_device，最后设置vb2_queue。

4.2 ioctl调用流程：从用户态到内核态

ioctl是V4L2的灵魂。用户空间发一个命令，比如VIDIOC_QUERYCAP查询能力，内核驱动就得响应。这个流程我拆成三步来讲。

第一步：用户空间发起调用

应用程序调用ioctl(fd, VIDIOC_QUERYCAP, &cap)。这个fd就是open("/dev/video0")拿到的文件描述符。

第二步：V4L2核心层分发

内核收到ioctl后，会通过video_device的v4l2_file_operations找到对应的处理函数。V4L2框架内部维护了一张巨大的命令表，把VIDIOC_XXX映射到具体的回调上。

第三步：驱动层执行

你的驱动只需要实现这些回调函数。比如vidioc_querycap，在里面填好设备信息就行。

static int my_vidioc_querycap(struct file *file, void *priv,
                               struct v4l2_capability *cap)
{
    strscpy(cap->driver, "qcom-isp", sizeof(cap->driver));
    strscpy(cap->card, "Qualcomm ISP Camera", sizeof(cap->card));
    cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
    return 0;
}

个人经验：我建议你在实现ioctl时，先打印一条调试日志。我曾经遇到一个bug，应用层一直报错说驱动不支持某个命令，结果发现是驱动里忘记注册对应的回调了。加个日志，问题一目了然。

4.3 Buffer管理机制：数据流转的核心

Buffer管理是V4L2里最复杂、也最容易出问题的地方。8155的摄像头数据量很大，4K@60fps的流，一秒的数据量就超过1GB。怎么高效地管理这些buffer，是个技术活。

V4L2的buffer管理分三种模式：

模式 说明 适用场景
V4L2_MEMORY_MMAP 内核分配buffer，用户通过mmap映射访问 大多数嵌入式场景，性能好
V4L2_MEMORY_USERPTR 用户自己分配buffer，传给内核使用 需要自定义内存管理的场景
V4L2_MEMORY_DMABUF 通过dma-buf共享buffer 多设备协同，比如ISP+GPU

我个人最常用的是MMAP模式。原因很简单：它让内核来管理内存，省心。在8155上，我一般会申请4个buffer，形成一个环形队列。

buffer流转的四个状态：

  1. QUEUED（已入队）：用户把空buffer交给驱动，等待填充数据。
  2. DEQUEUED（已出队）：驱动填好数据后，把buffer还给用户。
  3. STREAMON（流开启）：驱动开始采集数据，持续填充buffer。
  4. STREAMOFF（流关闭）：停止采集，所有buffer回到初始状态。

避坑指南：我曾经在8155上遇到一个诡异的问题：摄像头采集几秒钟后就卡死了。查了两天才发现，是应用层忘记把处理完的buffer重新入队。buffer队列空了，驱动没有空buffer可用，自然就卡住了。记住：每个buffer出队后，必须重新入队，否则驱动会饿死。

来看看核心的buffer操作流程：

// 1. 请求buffer
struct v4l2_requestbuffers req = {0};
req.count = 4;
req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
req.memory = V4L2_MEMORY_MMAP;
ioctl(fd, VIDIOC_REQBUFS, &req);

// 2. 查询并映射每个buffer
for (int i = 0; i < 4; i++) {
    struct v4l2_buffer buf = {0};
    buf.index = i;
    buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    buf.memory = V4L2_MEMORY_MMAP;
    ioctl(fd, VIDIOC_QUERYBUF, &buf);
    
    // mmap映射到用户空间
    buffers[i].start = mmap(NULL, buf.length,
                            PROT_READ | PROT_WRITE,
                            MAP_SHARED, fd, buf.m.offset);
    buffers[i].length = buf.length;
}

// 3. 把所有buffer入队
for (int i = 0; i < 4; i++) {
    struct v4l2_buffer buf = {0};
    buf.index = i;
    buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    buf.memory = V4L2_MEMORY_MMAP;
    ioctl(fd, VIDIOC_QBUF, &buf);
}

// 4. 开启流
enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
ioctl(fd, VIDIOC_STREAMON, &type);

// 5. 循环处理数据
while (1) {
    struct v4l2_buffer buf = {0};
    buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    buf.memory = V4L2_MEMORY_MMAP;
    ioctl(fd, VIDIOC_DQBUF, &buf);  // 取出填好的buffer
    
    // 处理数据...
    process_frame(buffers[buf.index].start, buf.bytesused);
    
    ioctl(fd, VIDIOC_QBUF, &buf);   // 重新入队
}

小技巧：在8155上，我习惯把buffer数量设为4个。太少容易丢帧，太多又浪费内存。4个刚好能形成一个稳定的流水线。另外，VIDIOC_DQBUF默认是阻塞的，如果你不想阻塞，可以用O_NONBLOCK打开设备，或者用select()/poll()来等待数据。

最后说一句，V4L2的buffer管理其实是个生产者-消费者模型。驱动是生产者，应用是消费者。理解了这个模型，你就能明白为什么buffer要入队出队、为什么队列不能空。我在8155上调优时，就是盯着这个模型，把buffer数量从3个改成4个，帧率就稳定了。

嗯，这一章的内容就到这里。下一章咱们聊聊怎么在8155上实际配置一个摄像头传感器，包括I2C通信和寄存器配置。到时候我会分享一个我踩过的坑——初始化时序没对齐，导致摄像头死活不出图。

← 上一章 📖 返回目录 下一章 →