第三章 驱动框架入门：Linux V4L2框架、M2M模型与海思MPP交互
好，咱们进入第三章。这一章我打算聊聊驱动开发中最核心的几个概念。说实话，很多新手一上来就被V4L2、M2M、MPP这些缩写搞懵了。我当年也一样，对着文档看了三天，脑子里还是一团浆糊。
别急，咱们一个一个拆开讲。你想想看，这些框架说白了就是一套标准接口。就像你去饭店吃饭，不管后厨怎么做菜，你只管看菜单点菜就行。驱动开发也是这个道理。
3.1 Linux V4L2框架：视频驱动的"通用语言"
V4L2，全称Video for Linux 2。它是Linux内核里专门为视频设备设计的驱动框架。我个人的理解，它就是一个"翻译官"——把上层应用的请求，翻译成底层硬件能听懂的命令。
为什么需要这个框架？
嗯，这里要注意。如果没有V4L2，每个摄像头、每个编解码器都得自己写一套ioctl接口。那应用层开发人员就惨了，换一个硬件就得重写一遍代码。V4L2统一了接口规范，应用层只需要open、ioctl、mmap、close这套标准流程，就能操作任何视频设备。
核心数据结构：
struct video_device：代表一个视频设备节点，比如/dev/video0struct v4l2_device：V4L2设备的顶层抽象struct vb2_queue：视频缓冲队列，管理数据流struct v4l2_format：描述图像格式，宽高、像素格式等
我在项目中遇到过一个问题：某个摄像头在V4L2框架下采集图像，总是丢帧。查了两天才发现，是vb2_queue的缓冲区数量配置太少。后来我把q->num_buffers从2改成了4，问题就解决了。这种坑，你不踩一次真的记不住。
3.2 M2M（内存到内存）设备模型：编解码的"流水线"
M2M，全称Memory to Memory。说白了就是数据从内存来，处理完再回内存去。这跟摄像头那种"从传感器采集到内存"的模式完全不同。
你想想看，编解码器的工作流程是什么？
- 应用层把原始码流（比如H.264数据）放到内存里
- 驱动把数据送给硬件编解码器
- 硬件处理完，把结果写回另一块内存
- 应用层从内存里取走解码后的YUV图像
整个过程都在内存里转，没有物理输入输出。这就是M2M的精髓。
在Linux内核里，M2M设备用struct v4l2_m2m_dev来管理。它维护了两个队列：
| 队列类型 | 作用 | 我习惯的命名 |
|---|---|---|
| OUTPUT队列 | 存放待处理的原始数据（码流） | src_queue |
| CAPTURE队列 | 存放处理后的结果数据（图像） | dst_queue |
我曾经调试过一个海思平台的解码器，发现解码出来的图像总是花屏。查了半天，原来是OUTPUT队列的码流数据没有按H.264的NAL单元对齐。驱动在解析时把半个NAL单元送给了硬件，硬件直接罢工了。嗯，从那以后我每次送码流前都会检查数据对齐。
个人经验：M2M驱动调试时，建议先确认两个队列的buffer状态。用cat /sys/kernel/debug/v4l2-m2m/xxx可以查看队列的实时状态，非常实用。
3.3 海思MPP平台与驱动的交互：从硬件到应用的"桥梁"
海思的MPP（Media Process Platform）是个好东西。它把底层的硬件编解码能力封装成一套API，应用层直接调用就行。但作为驱动开发者，你得知道MPP和V4L2驱动是怎么配合的。
我画个简单的交互流程：
应用层 (sample_vdec/sample_venc)
↓ 调用MPP API
MPP中间层 (libmpi.so)
↓ 通过ioctl进入内核
V4L2驱动 (hi_vdec/hi_venc)
↓ 操作寄存器
硬件编解码器 (VPSS/VENC/VDEC)你看，MPP其实是在V4L2驱动之上又包了一层。为什么海思要这么做？
我个人觉得有两个原因：
- 兼容性：MPP API是海思自己定义的，不管底层用V4L2还是其他框架，应用层代码不用改
- 性能优化：MPP可以做一些批量操作，比如一次提交多个buffer，减少用户态和内核态的切换次数
我记得有一次调试海思3519A的编码器，发现编码帧率上不去。用perf一分析，发现用户态和内核态切换太频繁了。后来在MPP层把buffer提交改成批量模式，帧率直接翻了一倍。
避坑指南：我曾经在MPP和V4L2的buffer管理上栽过跟头。MPP有自己的buffer池，V4L2也有自己的vb2队列。如果两者没有做好同步，很容易出现buffer泄漏或者死锁。建议在驱动初始化时，明确MPP和V4L2的buffer所有权归属。
3.4 实战：一个简单的M2M解码器驱动框架
光说不练假把式。咱们来看一个简化的M2M解码器驱动框架。这是我从海思SDK里提炼出来的核心逻辑：
static int hi_vdec_open(struct file *file)
{
struct hi_vdec_dev *dev = video_drvdata(file);
// 初始化M2M设备
dev->m2m_dev = v4l2_m2m_init(&hi_vdec_m2m_ops);
// 注册设备节点
video_register_device(dev->vfd, VFL_TYPE_VIDEO, -1);
return 0;
}
static void hi_vdec_device_run(void *priv)
{
struct hi_vdec_ctx *ctx = priv;
// 从OUTPUT队列取码流
struct vb2_buffer *src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
// 从CAPTURE队列取空buffer
struct vb2_buffer *dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
// 启动硬件解码
hi_vdec_start_hw(ctx, src, dst);
}这段代码看着简单，但里面藏着不少细节。比如hi_vdec_device_run这个回调，它是在中断上下文还是进程上下文？海思平台的做法是在中断下半部（tasklet）里调用，这样不会阻塞其他任务。
我建议你在写M2M驱动时，重点关注三个点：
- buffer的生命周期管理：谁分配、谁释放、什么时候可以重用
- 硬件中断处理：解码完成、编码完成、错误中断的处理逻辑
- 状态机设计：空闲、运行中、暂停、错误等状态的切换
核心要点总结：
- V4L2是视频驱动的标准框架，统一了应用层接口
- M2M模型适合编解码这类"内存到内存"的处理场景
- 海思MPP在V4L2之上封装，提供了更高效的API
- 驱动开发的核心是buffer管理和硬件交互
好了，这一章的内容就到这里。下一章咱们会深入海思的编解码硬件架构，看看那些寄存器到底是怎么工作的。到时候我会拿一个实际项目里的踩坑经历来讲解，保证让你印象深刻。