【原創】Linux v4l2框架分析
背景
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宏被調用；
4.2 流程分析
本節以omap3isp為例進行簡要分析，感覺直接看圖就可以了：
- buffer申請
- buffer enqueue
- buffer dequeue
- stream on
行文至此，主體講完了，相信看完本文應該有個大概的輪廓了，還有一些細節未進一步描述，就此打住。
參考
//lwn.net/Articles/416649/
《OMAP35x Technical Reference Manual (Rev. Y).pdf》
歡迎關注公眾號，不定期分享技術文章
