Whoops，上次写完《Linux DRM Graphic 显示简单介绍》博文后，心情还是蛮愉悦的，来来，这次在说说具体的显卡驱动。 

1. DRM 框架分解

DRM 框架提供了一系列的 IOCTL 行为，但是绝大部分可以分成两类行为：Graphics Execution Manager (GEM)、Kernel Mode-Setting (KMS)　　下面截图 WIKI 上一段总结：

Since then, the scope of DRM has been expanded over the years to cover more functionality previously handled by user space programs, such as framebuffer managing and mode setting, memory sharing objects and memory synchronization.[4][5] Some of these expansions had carried their own specific names, such as Graphics Execution Manager (GEM) or Kernel Mode-Setting (KMS), and the terminology prevails when the functionality they provide is specifically alluded. But they are really parts of the whole kernel DRM subsystem.

前者 GEM 主要是对 FrameBuffer 的管理，如显存的申请释放 (Framebuffer managing) ，显存共享机制 (Memory sharing objects)， 及显存同步机制 (Memory synchronization)，而后者 KMS 主要是完成显卡配置 (Display mode setting) . 
现在将 Rockchip drm 驱动和上面对应一下，rockchip_drm_gem* 对应的当然就是 GEM，rockchip_drm_vop* / analogix_dp-rockchip* / dw_hdmi-rockchip* 肯定指的就是 KMS，而我们这次也先玩玩后者 KMS （Kernel Mode Setting）. 

2. 显卡设备驱动

我们先引用下 WIKI 的一段话，来简述下显卡设备的组成：

Due to the fact that dies of modern GPUs found on graphics cards for desktop computers integrate “processing logic”, “display controller” and “hardware video acceleration” SIP cores, non-technical people don’t distinguish between these three very different components. SoCs on the other hand, regularly mix SIP from different developers, and, for example, ARM’s Mali SIP does not feature a display controller. For historical reasons, the DRM and the KMS of the Linux kernel were amalgamated into one component. They were split in 2013 for technical reasons.[16]

显卡主要是由三类设备组成：Processing logic 指的是神秘的 GPU 模块，Display controller 指的是 LCDC 控制器，Hardware video acceleration 指的就是具体的显示接口 HDMI / eDP / … 
根据上面的设备概念，我们来和具体驱动对应下：

[~/github_projs/linux] (analogix_dp_upstream) 837h28m $ ls drivers/gpu/drm/rockchip/
analogix_dp-rockchip.c  rockchip_drm_fbdev.c
dw_hdmi-rockchip.c      rockchip_drm_fbdev.h
Kconfig                 rockchip_drm_fb.h
Makefile                rockchip_drm_gem.c
rockchip_drm_drv.c      rockchip_drm_gem.h
rockchip_drm_drv.h      rockchip_drm_vop.c
rockchip_drm_fb.c       rockchip_drm_vop.h
 
 
1
2
3
4
5
6
7
8

1. Processing logic 很可惜不在我开发的目录中
2. Display controller 肯定是 VOP 驱动了 rockchip_drm_vop*
3. Hardware video acceleration 也就是 HDMI / eDP 驱动了 analogix_dp-rockchip* & dw_hdmi-rockchip*

而这次要要介绍的 DRM KMS (Kernel Mode Setting) 的概念，指的就是上面成员的集合，具体就是 VOP (Video Output Processor) / HDMI / eDP 端的驱动。DRM KMS 对于显卡设备驱动有三个概念 CRTC / Encoder / Connector，这三个概念很重要，但是很容易理解。CRTC 就是指 Display Controller，Encoder 就是指具体接口驱动 eDP / HDMI，Connector 指的是具体外接的屏幕 Monitor / Panel。

1. CRTC 的常用行为如下： 
   
   • DPMS (Display Power Manage System) 电源状态管理 (crtc_funcs->dpms)
   • 将 Framebuffer 转换成标准的 LCDC Timing ，其实就是一帧图像刷新的过程（crtc_funs->mode_set）
   • 帧切换，即在 VBlank 消影期间，切换 Framebuffer（crtc_funcs->page_flip）
   • Gamma 校正值调整（crtc_funcs->gamma_set）
2. Encoder 的常用行为如下： 
   
   • DPMS (Display Power Manage System) 电源状态管理 (encoder_funcs->dpms)
   • 将 VOP 输出的 lcdc Timing 打包转化为对应接口时序 HDMI TMDS / … (encoder_funcs->mode_set)
3. Connector 的常用行为如下： 
   
   • 获取上报 热拔插 Hotplug 状态
   • 读取并解析屏 (Panel) 的 EDID 信息

我简单以 HDMI Monitor 显示的过程为例，实例解析下 CRTC / Encoder / Connector 的行为： 
　1. 首先 HDMI 驱动检测到电视 Plugin 信号，读出电视的 EDID 信号，获取电视的分辨率信息 (DRM Connector)。 
　2. Userspace 将需要显示的数据填充在 framebuffer 里面，然后通过 libdrm 接口通知 VOP 设备开始显示。 
　3. 接着 VOP 驱动将 framebuffer 里面的数据转换成标准的 LCDC Timing 时序 (DRM CRTC)。 
　4. 同时 HDMI 驱动将 HDMI 硬件模块的 LCDC 时序配置与 VOP 输出时序一致，准备将输入的 LCDC Timing 转化为电视识别的 HDMI TMDS 信号 (DRM Encoder)。

具体 CRTC / Encoder / Connector 的驱动 API 细节，这次就不体现了，仅仅做一个概念性的介绍，以后再有机会在逐个分解说吧，最后还是 No Picture Say JB，盗用一张 GPU 同事画的一张 DRM 的框架流程图，整体和细节都把握的非常好。