【原创】Linuxv4l2框架分析

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

背景

  • Read the fucking source code! --By 鲁迅

  • A picture is worth a thousand words. --By 高尔基

说明：

  1. Kernel版本：4.14

  2. ARM64处理器，Contex-A53，双核

  3. 使用工具：Source Insight 3.5， Visio

1. 概述

  • V4L2(Video for Linux 2)：Linux内核中关于视频设备驱动的框架，对上向应用层提供统一的接口，对下支持各类复杂硬件的灵活扩展；

  • V4L2框架，主要包括v4l2-core、meida framework、videobuf2等模块，这也是本文将要展开的内容，仅提纲挈领；

开始吧。

2. v4l2-core

2.1 应用视角

先从应用的角度来看如何使用v4l2吧：

假如要进行视频数据采集，大体的步骤如上图左侧所示：

  1. 打开设备文件/dev/videoX；

  2. 根据打开的设备，查询设备能力集；

  3. 设置视频数据的格式、参数等；

  4. 分配buffer，这个buffer可以是用户态分配的，也可以是从内核中获取的；

  5. 开始视频流采集工作；

  6. 将buffer enqueue到v4l2框架，底层负责将视频数据填充后，应用层再将buffer dequeue以便获取数据，然后再将buffer enqueue，如此循环往复；

上图右侧是v4l2-core的大体框架，右侧是对硬件的抽象，要想理解好它，可以先看一下较常见的硬件拓扑结构：

  • 通常一个camera的模组如图所示，通常包括Lens、Sensor、CSI接口等，其中CSI接口用于视频数据的传输；

  • SoC的Mipi接口对接Camera，并通过I2C/SPI控制camera模组；

  • Camera模组中也可以包含ISP模块，用于对图像进行处理，有的SoC中也集成了ISP的IP，接收camera的raw数据后，进行图像处理；

2.2 数据结构

如果以上图的硬件为例，对摄像头的硬件该怎么来抽象呢？没错，就是以v4l2_device和v4l2_subdev来进行抽象,以v4l2_device来代表整个输入设备，以v4l2_subdev来代表子模块，比如CSI、Sensor等；

  • v4l2_device：对视频设备的整体进行抽象，可以看成是一个纽带，将各个子设备联系在一起，通常它会嵌入在其他结构体中以提供v4l2框架的功能，比如strcut isp_device；

  • v4l2_subdev：对子设备进行抽象，该结构体中包含的struct v4l2_subdev_ops是一个完备的操作函数集，用于对接各种不同的子设备，比如video、audio、sensor等，同时还有一个核心的函数集struct v4l2_subdev_core_ops，提供更通用的功能。子设备驱动根据设备特点实现该函数集中的某些函数即可；

  • video_device：用于向系统注册字符设备节点，以便用户空间可以进行交互，包括各类设置以及数据buffer的获取等，在该结构体中也能看到struct v4l2_ioctl_ops和struct vb2_queue结构体字段，这些与上文中的应用层代码编写息息相关；

  • 如果子设备不需要与应用层交互，struct v4l2_subdev中内嵌的video_device也可以不向系统注册字符设备；

  • video_device结构体，可以内嵌在其他结构体中，以便提供用户层交互的功能，比如struct isp_video；

  • 针对图中回调函数集，v4l2-core提供了一些实现，所以driver在实现时，非特殊情况下可以不用重复造轮子；

2.3 流程分析

来进一步看一下内部的注册，及调用流程吧：

  • 在驱动实现中，驱动结构体中内嵌struct video_device，同时实现struct v4l2_file_operations结构体中的函数，最终通过video_register_device向提供注册；

  • v4l2_register_device函数通过cdev_add向系统注册字符设备，并指定了file_operations，用户空间调用open/read/write/ioctl等接口，便可回调到驱动实现中；

  • v4l2_register_device函数中，通过device_register向系统注册设备，会在/sys文件系统下创建节点；

完成注册后，用户空间便可通过文件描述符来进行访问，从应用层看，大部分都是通过ioctl接口来完成，流程如下：

  • 用户层的ioctl回调到__video_do_ioctl中，该函数会对系统提供的struct v4l2_ioctl_info v4l2_ioctls[]表进行查询，找到对应的项后进行调用；

  • 驱动做的工作就是填空题，实现对应的回调，在合适的时候被调用；

下一个小节，让我们看看更复杂一点的情况。

3. media framework

3.1 问题引入

为了更好的描述，本节以omap3isp为例，先看一下它的硬件构成：

  • CSI：camera接口，接收图像数据，RGB/YUV/JPEG等；

  • CCDC：视频处理前端，CCDC为图像传感器和数字视频源提供接口，并处理图像数据；

  • Preview/Resizer：视频处理后端，Preview提供预览功能，可针对不同类型的传感器进行定制，Resizer提供将输入图像数据按所需的显示或视频编码分辨率调整大小的方法；

  • H3A/HIST：静态统计模块，H3A支持AF、AWB、AE的回路控制，HIST根据输入数据，提供各种3A算法所需的统计数据；

上述硬件模块，可以对应到驱动结构体struct isp_device中的各个字段。

omap3isp的硬件模块，支持多种数据流通路，它并不是唯一的，以RGB为例，如下图：

  • Raw RGB数据进入ISP模块后，可以在运行过程中，根据实际的需求进行通路设置；

  • 所以，重点是：它需要动态设置路径！

那么，软件该如何满足这种需求呢？

3.2 框架

没错，pipeline框架的引入可以解决这个问题。说来很巧，我曾经也实现过一个类似的框架，在阅读media framework时有一种似曾相识的感觉，核心的思想大体一致。

  • 模块之间相互独立，通过struct media_entity来进行抽象，通常会将struct media_entity嵌入到其他结构中，以支持media framework功能；

  • 模块包含struct media_pad，pad可以认为是端口，与其他模块进行联系的媒介，针对特定模块来说它是确定的；

  • pad通过struct media_link来建立连接，指定source和sink，即可将通路建立起来；

  • 各个模块之间最终建立一条数据流，便是一条pipeline了，同一条pipeline中的模块，可以根据前一个模块查找到下一个模块，因此也可以很方便进行遍历，并做进一步的设置操作；

因此，只需要将struct media_entity嵌入到特定子模块中，最终便可以将子模块串联起来，构成数据流。所以，omap3isp的驱动中，数据流就如下图所示：

  • video devnode代表video device，也就是前文中提到的导出到用户空间的节点，用于与用户进行控制及数据交互；

  • 每个模块分别有source pad和sink pad，从连接图就可以看出，数据通路灵活多变；

  • 至于数据通路选择问题，可以在驱动初始化的时候进行链接创建，比如isp_create_links；

还是看一下数据结构吧：

  • media_device：与v4l2_device类似，也是负责将各个子模块集中进行管理，同时在注册的时候，会向系统注册设备节点，方便用户层进行操作；

  • media_entity、media_pad、media_link等结构体的功能在上文中描述过，注意，这几个结构体会添加到media_device的链表中，同时它们结构体的开始字段都需是struct media_gobj，该结构中的mdev将会指向它所属的media_device。这种设计方便结构之间的查找；

  • media_entity中包含多个media_pad，同时media_pad又会指向它所属的media_entity；

  • media_graph和media_pipeline是media_entity的集合，直观来理解，就是由一些模块构成的一条数据通路，由一个统一的数据结构来组织管理；

罗列一下常见的几个接口吧，细节不表了：

/* 初始化entity的pads */
int media_entity_pads_init(struct media_entity *entity, u16 num_pads,
		      struct media_pad *pads);
/* 在两个entity之间创建link */
int media_create_pad_links(const struct media_device *mdev,
			   const u32 source_function,
			   struct media_entity *source,
			   const u16 source_pad,
			   const u32 sink_function,
			   struct media_entity *sink,
			   const u16 sink_pad,
			   u32 flags,
			   const bool allow_both_undefined);
/* 开始graph的遍历，从指定的entity开始 */
void media_graph_walk_start(struct media_graph *graph,
			    struct media_entity *entity);
/* 启动pipeline */
__must_check int media_pipeline_start(struct media_entity *entity,
				      struct media_pipeline *pipe);

将media framework和v4l2_device及v4l2_subdev结合起来，就可以将各个子设备构建pipeline，完美！

4. videobuf2

4.1 框架分析

  • 框架可以分成两个部分看：控制流+数据流，上文已经大概描述了控制流，数据流的部分就是video buffer了。

  • V4L2的buffer管理是通过videobuf2来完成的，它充当用户空间和驱动之间的中间层，并提供low-level，模块化的内存管理功能；

  • 上图大体包含了videobuf2的框架；

  • vb2_queue：核心的数据结构，用于描述buffer的队列，其中struct vb2_buffer *bufs[]是存放buffer节点的数组，该数组中的成员代表了vb2 buffer，并将在queued_list和done_list两个队列中进行流转；

  • struct vb2_buf_ops：buffer的操作函数集，由驱动来实现，并由框架通过call_bufop宏来对特定的函数进行调用；

  • struct vb2_mem_ops：内存buffer分配函数接口，buffer类型分为三种：1）虚拟地址和物理地址都分散，可以通过dma-sg来完成；2）物理地址分散，虚拟地址连续，可以通过vmalloc分配；3）物理地址连续，可以通过dma-contig来完成；三种类型也vb2框架中都有实现，框架可以通过call_memop来进行调用；

  • struct vb2_ops：vb2队列操作函数集，由驱动来实现对应的接口，并在框架中通过call_vb_qop宏被调用；

4.2 流程分析

本节以omap3isp为例进行简要分析，感觉直接看图就可以了：

  1. buffer申请

  1. buffer enqueue

  1. buffer dequeue

  1. stream on

行文至此，主体讲完了，相信看完本文应该有个大概的轮廓了，还有一些细节未进一步描述，就此打住。

参考

https://lwn.net/Articles/416649/

《OMAP35x Technical Reference Manual (Rev. Y).pdf》

欢迎关注公众号，不定期分享技术文章

作者：LoyenWang

出处：https://www.cnblogs.com/LoyenWang/

公众号：LoyenWang

版权：本文版权归作者和云海天共有

转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任

以上是 【原创】Linuxv4l2框架分析 的全部内容， 来源链接： utcz.com/z/519997.html

回到顶部