[[431515]]

本文轉(zhuǎn)載自微信公眾號「LoyenWang」，作者LoyenWang。轉(zhuǎn)載本文請聯(lián)系LoyenWang公眾號。

背景

• 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內(nèi)核中關(guān)于視頻設備驅(qū)動的框架，對上向應用層提供統(tǒng)一的接口，對下支持各類復雜硬件的靈活擴展;
• V4L2框架，主要包括v4l2-core、meida framework、videobuf2等模塊，這也是本文將要展開的內(nèi)容，僅提綱挈領(lǐng);

開始吧。

2. v4l2-core

2.1 應用視角

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

假如要進行視頻數(shù)據(jù)采集，大體的步驟如上圖左側(cè)所示：

• 打開設備文件/dev/videoX;
• 根據(jù)打開的設備，查詢設備能力集;
• 設置視頻數(shù)據(jù)的格式、參數(shù)等;
• 分配buffer，這個buffer可以是用戶態(tài)分配的，也可以是從內(nèi)核中獲取的;
• 開始視頻流采集工作;
• 將buffer enqueue到v4l2框架，底層負責將視頻數(shù)據(jù)填充后，應用層再將buffer dequeue以便獲取數(shù)據(jù)，然后再將buffer enqueue，如此循環(huán)往復;

上圖右側(cè)是v4l2-core的大體框架，右側(cè)是對硬件的抽象，要想理解好它，可以先看一下較常見的硬件拓撲結(jié)構(gòu)：

通常一個camera的模組如圖所示，通常包括Lens、Sensor、CSI接口等，其中CSI接口用于視頻數(shù)據(jù)的傳輸;

SoC的Mipi接口對接Camera，并通過I2C/SPI控制camera模組;

Camera模組中也可以包含ISP模塊，用于對圖像進行處理，有的SoC中也集成了ISP的IP，接收camera的raw數(shù)據(jù)后，進行圖像處理;

2.2 數(shù)據(jù)結(jié)構(gòu)

如果以上圖的硬件為例，對攝像頭的硬件該怎么來抽象呢?沒錯，就是以v4l2_device和v4l2_subdev來進行抽象,以v4l2_device來代表整個輸入設備，以v4l2_subdev來代表子模塊，比如CSI、Sensor等;

• v4l2_device：對視頻設備的整體進行抽象，可以看成是一個紐帶，將各個子設備聯(lián)系在一起，通常它會嵌入在其他結(jié)構(gòu)體中以提供v4l2框架的功能，比如strcut isp_device;
• v4l2_subdev：對子設備進行抽象，該結(jié)構(gòu)體中包含的struct v4l2_subdev_ops是一個完備的操作函數(shù)集，用于對接各種不同的子設備，比如video、audio、sensor等，同時還有一個核心的函數(shù)集struct v4l2_subdev_core_ops，提供更通用的功能。子設備驅(qū)動根據(jù)設備特點實現(xiàn)該函數(shù)集中的某些函數(shù)即可;
• video_device：用于向系統(tǒng)注冊字符設備節(jié)點，以便用戶空間可以進行交互，包括各類設置以及數(shù)據(jù)buffer的獲取等，在該結(jié)構(gòu)體中也能看到struct v4l2_ioctl_ops和struct vb2_queue結(jié)構(gòu)體字段，這些與上文中的應用層代碼編寫息息相關(guān);
• 如果子設備不需要與應用層交互，struct v4l2_subdev中內(nèi)嵌的video_device也可以不向系統(tǒng)注冊字符設備;
• video_device結(jié)構(gòu)體，可以內(nèi)嵌在其他結(jié)構(gòu)體中，以便提供用戶層交互的功能，比如struct isp_video;
• 針對圖中回調(diào)函數(shù)集，v4l2-core提供了一些實現(xiàn)，所以driver在實現(xiàn)時，非特殊情況下可以不用重復造輪子;

2.3 流程分析

來進一步看一下內(nèi)部的注冊，及調(diào)用流程吧：

• 在驅(qū)動實現(xiàn)中，驅(qū)動結(jié)構(gòu)體中內(nèi)嵌struct video_device，同時實現(xiàn)struct v4l2_file_operations結(jié)構(gòu)體中的函數(shù)，最終通過video_register_device向提供注冊;
• v4l2_register_device函數(shù)通過cdev_add向系統(tǒng)注冊字符設備，并指定了file_operations，用戶空間調(diào)用open/read/write/ioctl等接口，便可回調(diào)到驅(qū)動實現(xiàn)中;
• v4l2_register_device函數(shù)中，通過device_register向系統(tǒng)注冊設備，會在/sys文件系統(tǒng)下創(chuàng)建節(jié)點;

完成注冊后，用戶空間便可通過文件描述符來進行訪問，從應用層看，大部分都是通過ioctl接口來完成，流程如下：

用戶層的ioctl回調(diào)到__video_do_ioctl中，該函數(shù)會對系統(tǒng)提供的struct v4l2_ioctl_info v4l2_ioctls[]表進行查詢，找到對應的項后進行調(diào)用;

驅(qū)動做的工作就是填空題，實現(xiàn)對應的回調(diào)，在合適的時候被調(diào)用;

下一個小節(jié)，讓我們看看更復雜一點的情況。

3. media framework

3.1 問題引入

為了更好的描述，本節(jié)以omap3isp為例，先看一下它的硬件構(gòu)成：

• CSI：camera接口，接收圖像數(shù)據(jù)，RGB/YUV/JPEG等;
• CCDC：視頻處理前端，CCDC為圖像傳感器和數(shù)字視頻源提供接口，并處理圖像數(shù)據(jù);
• Preview/Resizer：視頻處理后端，Preview提供預覽功能，可針對不同類型的傳感器進行定制，Resizer提供將輸入圖像數(shù)據(jù)按所需的顯示或視頻編碼分辨率調(diào)整大小的方法;

H3A/HIST：靜態(tài)統(tǒng)計模塊，H3A支持AF、AWB、AE的回路控制，HIST根據(jù)輸入數(shù)據(jù)，提供各種3A算法所需的統(tǒng)計數(shù)據(jù);

上述硬件模塊，可以對應到驅(qū)動結(jié)構(gòu)體struct isp_device中的各個字段。

omap3isp的硬件模塊，支持多種數(shù)據(jù)流通路，它并不是唯一的，以RGB為例，如下圖：

• Raw RGB數(shù)據(jù)進入ISP模塊后，可以在運行過程中，根據(jù)實際的需求進行通路設置;
• 所以，重點是：它需要動態(tài)設置路徑!

那么，軟件該如何滿足這種需求呢?

3.2 框架

沒錯，pipeline框架的引入可以解決這個問題。說來很巧，我曾經(jīng)也實現(xiàn)過一個類似的框架，在閱讀media framework時有一種似曾相識的感覺，核心的思想大體一致。

• 模塊之間相互獨立，通過struct media_entity來進行抽象，通常會將struct media_entity嵌入到其他結(jié)構(gòu)中，以支持media framework功能;
• entity模塊包含struct media_pad，pad可以認為是端口，與其他模塊進行聯(lián)系的媒介，針對特定模塊來說它是確定的;
• pad通過struct media_link來建立連接，指定source和sink，即可將通路建立起來;
• 各個模塊之間最終建立一條數(shù)據(jù)流，便是一條pipeline了，同一條pipeline中的模塊，可以根據(jù)前一個模塊查找到下一個模塊，因此也可以很方便進行遍歷，并做進一步的設置操作;

因此，只需要將struct media_entity嵌入到特定子模塊中，最終便可以將子模塊串聯(lián)起來，構(gòu)成數(shù)據(jù)流。所以，omap3isp的驅(qū)動中，數(shù)據(jù)流就如下圖所示：

• video devnode代表video device，也就是前文中提到的導出到用戶空間的節(jié)點，用于與用戶進行控制及數(shù)據(jù)交互;
• 每個模塊分別有source pad和sink pad，從連接圖就可以看出，數(shù)據(jù)通路靈活多變;
• 至于數(shù)據(jù)通路選擇問題，可以在驅(qū)動初始化的時候進行鏈接創(chuàng)建，比如isp_create_links;

還是看一下數(shù)據(jù)結(jié)構(gòu)吧：

• media_device：與v4l2_device類似，也是負責將各個子模塊集中進行管理，同時在注冊的時候，會向系統(tǒng)注冊設備節(jié)點，方便用戶層進行操作;
• media_entity、media_pad、media_link等結(jié)構(gòu)體的功能在上文中描述過，注意，這幾個結(jié)構(gòu)體會添加到media_device的鏈表中，同時它們結(jié)構(gòu)體的開始字段都需是struct media_gobj，該結(jié)構(gòu)中的mdev將會指向它所屬的media_device。這種設計方便結(jié)構(gòu)之間的查找;
• media_entity中包含多個media_pad，同時media_pad又會指向它所屬的media_entity;
• media_graph和media_pipeline是media_entity的集合，直觀來理解，就是由一些模塊構(gòu)成的一條數(shù)據(jù)通路，由一個統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)來組織管理;

羅列一下常見的幾個接口吧，細節(jié)不表了：

/* 初始化entity的pads */ 
int media_entity_pads_init(struct media_entity *entity, u16 num_pads, 
        struct media_pad *pads); 
 
/* 在兩個entity之間創(chuàng)建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結(jié)合起來，就可以將各個子設備構(gòu)建pipeline，完美!

4. videobuf2

4.1 框架分析

• 框架可以分成兩個部分看：控制流+數(shù)據(jù)流，上文已經(jīng)大概描述了控制流，數(shù)據(jù)流的部分就是video buffer了。
• V4L2的buffer管理是通過videobuf2來完成的，它充當用戶空間和驅(qū)動之間的中間層，并提供low-level，模塊化的內(nèi)存管理功能;

• 上圖大體包含了videobuf2的框架;
• vb2_queue：核心的數(shù)據(jù)結(jié)構(gòu)，用于描述buffer的隊列，其中struct vb2_buffer *bufs[]是存放buffer節(jié)點的數(shù)組，該數(shù)組中的成員代表了vb2 buffer，并將在queued_list和done_list兩個隊列中進行流轉(zhuǎn);
• struct vb2_buf_ops：buffer的操作函數(shù)集，由驅(qū)動來實現(xiàn)，并由框架通過call_bufop宏來對特定的函數(shù)進行調(diào)用;
• struct vb2_mem_ops：內(nèi)存buffer分配函數(shù)接口，buffer類型分為三種：1)虛擬地址和物理地址都分散，可以通過dma-sg來完成;2)物理地址分散，虛擬地址連續(xù)，可以通過vmalloc分配;3)物理地址連續(xù)，可以通過dma-contig來完成;三種類型也vb2框架中都有實現(xiàn)，框架可以通過call_memop來進行調(diào)用;
• struct vb2_ops：vb2隊列操作函數(shù)集，由驅(qū)動來實現(xiàn)對應的接口，并在框架中通過call_vb_qop宏被調(diào)用;

4.2 流程分析

本節(jié)以omap3isp為例進行簡要分析，感覺直接看圖就可以了：

buffer申請 

buffer enqueue 

buffer dequeue 

stream on 

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

參考

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

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