作者：Nick

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

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

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

② 會先給出DRM+KMS驅動框架下的主要模塊，并針對上述硬件子模塊分析對應的內核驅動部分；

DRI在片上系統的硬件構成

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

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

Connector

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

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

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

①通過connector讀出的顯示器支持的參數；
② 內核靜態配置或devicetree傳入的參數；
③ 用戶空間輸入的參數）

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

Encoder

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

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

CRTC

CRTC的任務是從Framebuffer中讀出待顯示的圖像，并按照相應的格式輸出給Encoder（本處的CRTC功能受限，相關格式配置只能通過配置硬件IP參數來改變，而不能通過內核）。在本例中，CRTC的硬件構成如下：

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

② Video Timing Controller IP，根據內核相應配置輸出與視頻流匹配的幀、行同步信號；

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

如下圖：

Planes

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

Framebuffer

Framebuffer對應著存儲空間中的圖像數據，此處對應硬件為DDR。

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

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

DRI在Linux Kernel內的軟件構成

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

Framebuffer

我們知道Framebuffer是存儲待顯示圖像信息的空間，因此，Framebuffer相關驅動中也就是對內存的操作，也就涉及到下面兩個部分：
① 對內存的管理（如GEM，for Graphics Execution Manager）
② 內存中數據的更顯方式（如DMA等）

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

在Linux Kernel下的默認實現方式是CMA（Contiguous Memory Allocator）實現的，內核中對應代碼是：

drivers/gpu/drm/drm_fb_cma_helper.c

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

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

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

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

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

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

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

(顯存管理)

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

（顯存更新驅動接口）

drivers/gpu/drm/ati_pcigart.c

drivers/gpu/drm/ati_agpsupport.c

CRTC

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

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

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

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

page_flip解決的問題很簡單：

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

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

Planes

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

的創建、更新、銷毀，其中圖層的更新（多個圖層的疊加），通過struct中的drm_plane_funcs來實現。

比較形象的例子如下：

Connector & Encoder

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

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

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

編輯：hfy