以xc7z010 SOPC為例的DRM-KMS方案分析

作者：Nick

在上一小節(jié)《Linux GUI加速(1)_GUI系統(tǒng)概述》中，我們從應(yīng)用層到kernel層大致分析了linux中的圖形界面的構(gòu)成，并在最后給出了kernel中DRM+KMS的軟件顯示框架以及accelerate logic+framebuffer+displayport的硬件結(jié)構(gòu)。在這一子篇會將這兩塊內(nèi)容詳細展開。

本篇主要以Xilinx的xc7z010 的SOPC（zybo的開發(fā)板）為硬件平臺，在以下幾方面介紹：

① 以zynq 7000的邏輯資源（PL）搭建CRTC/Encoder/Connector硬件模塊，以HDMI輸出接口為例，介紹各個模塊的接口特性（Framebuffer對應(yīng)著物理的DDR部分）；

② 會先給出DRM+KMS驅(qū)動框架下的主要模塊，并針對上述硬件子模塊分析對應(yīng)的內(nèi)核驅(qū)動部分；

DRI在片上系統(tǒng)的硬件構(gòu)成

在各類SOC上，CRTC+Endode+Connector一般是集成在一個外設(shè)模塊掛在系統(tǒng)總線上，以ARM為例，CRTC/Endoder等需要配置的外設(shè)模塊，配置接口掛在APB總線，數(shù)據(jù)接口直接在AHB總線上，實現(xiàn)和Framebuffer的高速通信。

我們按照connector-->encoder-->crtc-->framebuffer的順序倒過來介紹吧。

Connector

Connector其實就是和顯示器連接的物理接口，常見的有VGA/HDMI/DVI/DP等。以HDMI為例，HDMI的接口信號主要由以下幾組信號組成：

① 1組TMDS clock：差分時鐘用于同步信號驅(qū)動；
② 3組TMDS data：查分數(shù)據(jù)傳輸視頻信號；
③ 1組I2C：用于EDID的獲取；
④ 1組音頻總線；

（注：EDID全稱是Extended Display Identification Data(擴展顯示標識數(shù)據(jù))，目的是讓視頻信號輸出設(shè)備輸出前獲取到存儲在顯示器內(nèi)部的相關(guān)參數(shù)，如支持的分辨率、幀率、圖像格式：RGB等，因此，整個輸出的控制參數(shù)是由以下幾個部分綜合決定的：

①通過connector讀出的顯示器支持的參數(shù)；
② 內(nèi)核靜態(tài)配置或devicetree傳入的參數(shù)；
③ 用戶空間輸入的參數(shù)）

HDMI類型的connector的任務(wù)就是輸出顯示器解碼芯片所需的信號時序（主要是TMDS clock以及TMDS data）。

Encoder

Encoder比較好理解，在此處其實就是將一定格式的圖像信號（如RGB、YUV等）編碼成connector需要輸出的信號。以HDMI為例，幀/行同步/顯示內(nèi)容都是通過TMDS data的串行總線輸出的，那么并行的時序按照HDMI的標準編碼為串行順序則是Encoder的任務(wù)；

在本片中的XC7Z010 SOPC中Encoder+Connector如下：

CRTC

CRTC的任務(wù)是從Framebuffer中讀出待顯示的圖像，并按照相應(yīng)的格式輸出給Encoder（本處的CRTC功能受限，相關(guān)格式配置只能通過配置硬件IP參數(shù)來改變，而不能通過內(nèi)核）。在本例中，CRTC的硬件構(gòu)成如下：

① AXI Video Direct Memory Access IP，通過AXI4總線獲取DDR中Framebuffer數(shù)據(jù)，轉(zhuǎn)為video-stream流格式的圖像信息；

② Video Timing Controller IP，根據(jù)內(nèi)核相應(yīng)配置輸出與視頻流匹配的幀、行同步信號；

③ AXI4-Stream to Video Out IP，將串行視頻流轉(zhuǎn)化為指定格式（IP配置）、指定分辨率（內(nèi)核配置）的時序；

如下圖：

Planes

Plane其實就是圖層，實際輸出的圖像往往由多個圖層疊加而成（想象一下photoshop的過程），比如主圖層，顯示光標的圖層，其中有些圖層由硬件加速模塊生成，本例中不涉及，因此所有plane的相關(guān)操作都由軟件實現(xiàn)，不涉及到任何硬件結(jié)構(gòu)。

Framebuffer

Framebuffer對應(yīng)著存儲空間中的圖像數(shù)據(jù)，此處對應(yīng)硬件為DDR。

麻雀雖小，五臟俱全，次例程中的顯示框架非常簡單，但也包含了Framebuffer、CRTC、Planes、Encoder、Connector5個組件，片內(nèi)硬件結(jié)構(gòu)如下：

（PS：Dynamic Clock Generator生成顯示子系統(tǒng)中各組件所需的驅(qū)動時鐘，由Linux中的common clock framework統(tǒng)一管理）

DRI在Linux Kernel內(nèi)的軟件構(gòu)成

按照DRI中幾個組件分別介紹。

Framebuffer

我們知道Framebuffer是存儲待顯示圖像信息的空間，因此，F(xiàn)ramebuffer相關(guān)驅(qū)動中也就是對內(nèi)存的操作，也就涉及到下面兩個部分：
① 對內(nèi)存的管理（如GEM，for Graphics Execution Manager）
② 內(nèi)存中數(shù)據(jù)的更顯方式（如DMA等）

對于第一點，GEM主要完成的事情是：
① 對圖像內(nèi)存（顯存）的空間開辟、釋放；
② 不同硬件對同一顯存資源訪問下的管理；

在Linux Kernel下的默認實現(xiàn)方式是CMA（Contiguous Memory Allocator）實現(xiàn)的，內(nèi)核中對應(yīng)代碼是：

drivers/gpu/drm/drm_fb_cma_helper.c

這里稍微提一下CMA，CMA是個好東西，不僅在顯存管理中有應(yīng)用，在所有軟硬件協(xié) 同處理中同樣起這重要的作用。在一般的硬件（片內(nèi)硬件加速模塊）加速方案中，一般實現(xiàn)方式如下：

① linux kernel通過device-tree傳入CMA配置所需的配置參數(shù)供CMA開辟相應(yīng)的物理內(nèi)存 空間（不被Cache到），并且相應(yīng)的信息（物理空間首地址，size等）通過/dev/device 映射到用戶空間；

② DMA可以將加速模塊預(yù)處理后的數(shù)據(jù)，根據(jù)已知參數(shù)（開辟的物理地址），傳遞到共享空間中供軟件訪問；

struct drm_framebuffer{
[...]
const struct drm_format_info *format;
[...]
}

? format用于描述內(nèi)存空間的組成，使用FOURCC（four-character code）制式，結(jié)構(gòu)體中的pitch、offset 4個元素分別用于計算FOURCC4個圖層中的內(nèi)存長寬參數(shù)；（width和height用于描述顯示的長寬參數(shù)）；

? DRI中支持下面這三種格式圖像：
① RGB：R/G/B分別存于不同的圖層中；
② YUV：不同壓縮格式下的YUV存儲方式不一；
③ C8：通過存儲一塊映射到RGB的映射表來實現(xiàn)圖像信息存儲；

framebuffer中在不同格式下所需要處理的圖層的數(shù)量不一，具體的顯存處理、格式解析主要在下列源碼表中：

(顯存管理)

drivers/gpu/drm/drm_framebuffer.c

drivers/gpu/drm/drm_gem.c

drivers/gpu/drm/drm_gem_cma_helper.c

drivers/gpu/drm/drm_fb_cma_helper.c

drivers/gpu/drm/drm_fb_framebuffer_helper.c

drivers/gpu/drm/drm_fb_fourcc.c

drivers/gpu/drm/drm_fb_cma_helper.c

drivers/gpu/drm/drm_fb_cma_helper.c

drivers/gpu/drm/drm_fb_cma_helper.c

（顯存更新驅(qū)動接口）

drivers/gpu/drm/ati_pcigart.c

drivers/gpu/drm/ati_agpsupport.c

CRTC

CRTC雖然字面上意思為陰極射線顯像管控制器，但CRT在普通顯示設(shè)備中早已被淘汰，DRI中CRTC主要承擔(dān)的作用：
① 配置適合顯示器的分辨率（kernel）并輸出相應(yīng)時序（hardware logic）；
② 掃描framebuffer送顯到一個或多個顯示設(shè)備中；
③ 更新framebuffer；

上述功能的主要通過struct drm_crtc_funcs和struct drm_crtc_helper_funcs這兩個描述符實現(xiàn)：

drm_crtc_funcs中的兩個重要句柄set_config和page_flip，其中，

set_config主要任務(wù)是：
① 更新待送顯的framebuffer中數(shù)據(jù)；
② 根據(jù)（之前說的EDID讀出支持的配置，device-tree對內(nèi)核的配置以及用戶空間的配置）參數(shù)配置軟件參數(shù)并控制相應(yīng)的寄存器（在本例中的VDMA及VTC的行列像素值等寄存器）；
③ 將Encoder和connector的信息送給CRTC模塊。

page_flip解決的問題很簡單：

? 必須得保證CRTC在讀取framebuffer的時候，framebuffer里的幀不會被修改而產(chǎn)生竄幀的情況，采用的解決方式也是軟硬件異構(gòu)處理時常見的乒乓緩存的方式。

當page_flip完成后，會通過event通知用戶層準備好下一幀的數(shù)據(jù)；

Planes

不涉及到GPU的話，planes沒有那么復(fù)雜，主要是負責(zé)：
? 主圖層;
? 移動光標圖層；
? 覆蓋圖層；

的創(chuàng)建、更新、銷毀，其中圖層的更新（多個圖層的疊加），通過struct中的drm_plane_funcs來實現(xiàn)。

比較形象的例子如下：

Connector & Encoder

由于Connector和Encoder是SOC與外設(shè)直接打交道的地方，因此對應(yīng)著不同SOC也是驅(qū)動適配修改最頻繁的地方。DRI中這兩塊通過適配struct drm_connector_helper_funcs和struct drm_encoder_helper_funcs來實現(xiàn)。

Linux Kernel中的DRM+KMS中涉及到的點太多，由于能力和時間問題，沒能遍歷一遍，只能根據(jù)自己認為的重點討論一邊，但有些點我認為比較重要的，但沒能深入了解，比如：

? 硬件graphic加速和DRM的交互邏輯
? CRTC的Atomic刷新機制的具體實現(xiàn)方式等，如果大家能夠交流一下自己的理解，那再好不過了。

編輯：hfy