【原創】Linux v4l2框架分析

背景

• 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申請

2. buffer enqueue

3. buffer dequeue

4. stream on

行文至此，主體講完了，相信看完本文應該有個大概的輪廓了，還有一些細節未進一步描述，就此打住。

參考

https://lwn.net/Articles/416649/
《OMAP35x Technical Reference Manual (Rev. Y).pdf》

歡迎關注公衆號，不定期分享技術文章