本文共 28322 字，大约阅读时间需要 94 分钟。

这篇文章详细分析了V4L2用户空间和kernel层driver的交互过程，目的只有一个：
更清晰的理解V4L2视频驱动程序的系统结构，驱动编程方法，为以后开发视频驱动打好基础

既然从用户层出发探究驱动层，这里先贴出应用层code：
上面code中我已经标注出程序顺序指向的步骤1--14步，下面将一一说明应用从做这14步时驱动层是怎样响应，变化过程， 驱动加载初始化部分上一篇文章已经说过了
正式开始取经之路哇。。。。 。。。

STEP 1：
fd = open (dev_name, O_RDWR| O_NONBLOCK, 0);
打开字符设备，这个字符设备是video_device_register时创建的，code在v4l2_dev.c中，具体：
重点在标注部分，通过这个V4L2的API调用我们自己驱动程序中定义的open方法，我们自己的open方法所属的fops是在vivi.c驱动程序的vivi_create_instance方法中 video_device_register之前关联进来的

这个open方法只是初始化了一个v4l2_fh，并关联到filp->private中，方便以后使用
这里设置V4L2_FL_USES_V4L2_FH这个标志位，设置优先级为UNSET，如果我们的自己驱动程序实现了，支持
VIDIOC_SUBSCRIBE_EVENT,那么v4l2_event_init，在events初始化中初始化链表，并设置sequence为-1，如果不支持，则设置fh->events为NULL
最后add list

STEP 2：
if (-1 == xioctl (fd, VIDIOC_QUERYCAP, &cap))
这么调用完成下面过程，不行的从驱动层获取cap。直到成功拿到我们想要的数据
也就是调用驱动层的ioctl方法，从v4l2 api中的ictol 调用我们自己定义的ioctl ，这中间的过程不在多做说明，我们自己的驱动的控制过程由v4l2_ioctl.c这个文件中的方法实现，一个很庞大的switch
值得一提的是，慢慢后面你会明白的，这里 v4l2_ioctl.c这个文件中的方法实现其实只是会中转站，它接着就回调了我们自己驱动程序中定义的控制接口，后面再说吧
这里这个 __video_do_ioctl 方法其实完全做了我们所有的控制过程，又为什么又要经过video_usercopy这个方法呢，不妨看一看这个方法
自我感觉这个方法还是有很多精妙之处的，主要的控制过程是在我标注的地方调用完成的，这个调用之前做check动作，检查用户端发来的命令是否合法，
最重要的是把用户端的数据copy到kernel 端；而这个调用之后，则是我们处理完我们的动作之后，我们在这里吧用户端请求的数据从kernel 端copy到用户端
这样做的好处是显而易见的，任务明确，控制只做控制，用户空间和kernel空间数据的copy在所有控制之前，控制之后进行
以上动作做完之后，进入庞大的控制中枢，这来开始至贴出具体到某一个控制的代码，否则code过大，不易分析：

这来调用了我们自己驱动中填充的v4l2_ioctl_ops结构体，从这里开始，我上面说到的话得到了验证，这就是linux 中API 的强大之处
作为中间层的这个控制中枢又回调驱动自己定义编写的控制
这来做的事情很简单，只是将配置信息保存到cap这个变量中，之后上传给用户空间

STEP 3：
/* 3. VIDIOC_CROPCAP查询驱动的修剪能力*/
/* 这里在vivi 驱动中我们没有实现此方法，即不支持此操作*/
if (0 == xioctl (fd, VIDIOC_CROPCAP, &cropcap))
这个判断在中间层控制中枢中进行的，check到我们自己的驱动中没有这个控制功能的支持
所以这里的 STEP 4同样不会进行

STEP 5：
/* 5. VIDIOC_S_FMT设置当前驱动的频捕获格式*/
if (-1 == xioctl (fd, VIDIOC_S_FMT, &fmt))
对应到控制中心是这样的

以后根据不同的type 决定了我们自己驱动程序中不同的控制实现，这个type是根据用户空间的设置而定的，还包括其他几个参数，如下：
这里根据设定的type，所以驱动程序的处理过程如下：


STEP6 ：
/* 6. VIDIOC_REQBUFS分配内存*/
if (-1 == xioctl (fd, VIDIOC_REQBUFS, &req))
中间层控制中枢：
驱动中实现：
到了这里来到了这个全新的话题，实现
vb2_reqbufs ( & dev - > vb_vidq ,  p ) ;
这里暂且不讨论这个方法，相对较复杂，待日后研究，先把注释部分放到这里，包括其他内存操作，之后深入研究补充，专门作为一篇整理
/**
 * Should be called from vidioc_reqbufs ioctl handler of a driver.
 * This function:
 * 1) verifies streaming parameters passed from the userspace,
 * 2) sets up the queue,
 * 3) negotiates number of buffers and planes per buffer with the driver to be used during streaming,
 * 4) allocates internal buffer structures (struct vb2_buffer), according to the agreed parameters,
 * 5) for MMAP memory type, allocates actual video memory, using the memory handling/allocation routines provided during queue initialization
 * If req->count is 0, all the memory will be freed instead.
 * If the queue has been allocated previously (by a previous vb2_reqbufs) call
 * and the queue is not busy, memory will be reallocated.
 * The return values from this function are intended to be directly returned from vidioc_reqbufs handler in driver.
 */

STEP 7：
/* 7. VIDIOC_QUERYBUF把VIDIOC_REQBUFS中分配的数据缓存转换成物理地址*/
if (-1 == xioctl (fd, VIDIOC_QUERYBUF, &buf))
中间层控制中枢：
驱动中控制实现：
/**
 * Should be called from vidioc_querybuf ioctl handler in driver.
 * This function will verify the passed v4l2_buffer structure and fill the
 * relevant information for the userspace.
 * The return values from this function are intended to be directly returned from vidioc_querybuf handler in driver.
 */

STEP 8：
/* 8. VIDIOC_QBUF把数据从缓存中读取出来*/
if (-1 == xioctl (fd, VIDIOC_QBUF, &buf))
中间层控制中枢：
驱动中控制实现：

/**
 * Should be called from vidioc_qbuf ioctl handler of a driver.
 * This function:
 * 1) verifies the passed buffer,
 * 2) calls buf_prepare callback in the driver (if provided), in which driver-specific buffer initialization can be performed,
 * 3) if streaming is on, queues the buffer in driver by the means of buf_queue callback for processing.
 * The return values from this function are intended to be directly returned from vidioc_qbuf handler in driver.
 */

STEP 9：
/* 9. VIDIOC_STREAMON开始视频显示函数*/
if (-1 == xioctl (fd, VIDIOC_STREAMON, &type))
中间层控制中枢：
驱动控制实现;

/**
 * Should be called from vidioc_streamon handler of a driver.
 * This function:
 * 1) verifies current state
 * 2) starts streaming and passes any previously queued buffers to the driver
 * The return values from this function are intended to be directly returned from vidioc_streamon handler in the driver.
 */

STEP 10：
/* 10. poll method*/
select (fd + 1, &fds, NULL, NULL, &tv);
从V4L2驱动API开始：
驱动实现：
/**
 * This function implements poll file operation handler for a driver.
 * For CAPTURE queues, if a buffer is ready to be dequeued, the userspace will be informed that the file descriptor of a video device is available for reading.
 * For OUTPUT queues, if a buffer is ready to be dequeued, the file descriptor will be reported as available for writing.
 * The return values from this function are intended to be directly returned from poll handler in driver.
 */

STEP 11：
/* 11. VIDIOC_DQBUF把数据放回缓存队列*/
if (-1 == xioctl (fd, VIDIOC_DQBUF, &buf))
中间层控制中枢：
驱动控制实现：

/**
 * Should be called from vidioc_dqbuf ioctl handler of a driver.
 * This function:
 * 1) verifies the passed buffer,
 * 2) calls buf_finish callback in the driver (if provided), in which driver can perform any additional operations that may be required before returning the buffer to userspace, such as cache sync,
 * 3) the buffer struct members are filled with relevant information for the userspace.
 * The return values from this function are intended to be directly returned from vidioc_dqbuf handler in driver.
 */

STEP 12：
/*12. VIDIOC_QBUF把数据从缓存中读取出来*/
if (-1 == xioctl (fd, VIDIOC_QBUF, &buf))
中间层控制中枢：
驱动控制实现：


STEP 13：
/*13. VIDIOC_STREAMOFF结束视频显示函数*/
if (-1 == xioctl (fd, VIDIOC_STREAMOFF, &type))
中间层控制中枢：
驱动控制实现：


STEP 13：
/*13. VIDIOC_STREAMOFF结束视频显示函数*/
if (-1 == xioctl (fd, VIDIOC_STREAMOFF, &type))
中间层控制中枢：
驱动控制实现：


STEP 14：
/*14. close method*/
close(fbfd);


到此为止，整个过程算是基本完结了，不过其中videobuf2_core.c 在我看来自己必须专门钻研一下了
videobuf2_core .c 是视频数据传输的核心
也可以说是视频驱动的重中之重
待续。。。。。。

转载地址：https://linus.blog.csdn.net/article/details/45745101 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！