背景

Read the fucking source code! --By 魯迅
A picture is worth a thousand words. --By 高爾基

說明：

Kernel版本：4.14
ARM64處理器，Contex-A53，雙核
使用工具：Source Insight 3.5， Visio

1. 概述

V4L2(Video for Linux 2)：Linux內核中關于視頻設備驅動的框架，對上向應用層提供統一的介面，對下支持各類復雜硬體的靈活擴展；
V4L2框架，主要包括v4l2-core、meida framework、videobuf2等模塊，這也是本文將要展開的內容，僅提綱挈領；

開始吧，

2. v4l2-core

2.1 應用視角

先從應用的角度來看如何使用v4l2吧：

假如要進行視頻資料采集，大體的步驟如上圖左側所示：

打開設備檔案/dev/videoX；
根據打開的設備，查詢設備能力集；
設定視頻資料的格式、引數等；
分配buffer，這個buffer可以是用戶態分配的，也可以是從內核中獲取的；
開始視頻流采集作業；
將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宏被呼叫；