前言
在前面的《最简单的DRM应用程序》系列文章中，我们学习了如何使用 libdrm 接口编写 DRM 应用程序。从本篇开始，我们将进入一个全新的世界，一起来学习如何在 kernel 空间编写 DRM 驱动程序。
Objects
在开始编写 DRM 驱动程序之前，我有必要对 DRM 内部的 Objects 进行一番介绍。因为这些 Objects 是 DRM 框架的核心，它们缺一不可。
上图蓝色部分则是对物理硬件的抽象，黄色部分则是对软件的抽象。虚线以上的为 drm_mode_object，虚线以下为 drm_gem_object。
之前曾在《DRM（Direct Rendering Manager）学习简介》中对这些 objects 做过简要介绍，作为本篇的重中之重，我觉得有必要再强调一下这些 objects 的概念：
| object | 说明 |
|---|---|
| crtc | RGB 信号发生源（TCON），显存切换控制器（Dislay Controller） |
| plane | Display Controller 的数据源通道，每个 crtc 至少要有一个 plane |
| encoder | RGB 信号转换器（DSI Contoller），同时也控制显示设备的休眠唤醒 |
| connector | 凡是能获取到显示参数的硬件设备，但通常和 encoder 绑定在一起 |
| framebuffer | 只用于描述显存信息（如 format、pitch、size 等），不负责显存的分配释放 |
| property | atomic 操作的基础，任何想要修改的参数都可以做成 property，供用户空间使用 |
| gem | 负责显存的分配、映射和释放 |
这些 objects 之间的关系：
通过上图可以看到，plane 是连接 framebuffer 和 crtc 的纽带，而 encoder 则是连接 crtc 和 connector 的纽带。与物理 buffer 直接打交道的是 gem 而不是 framebuffer。
需要注意的是，上图蓝色部分即使没有实际的硬件与之对应，在软件驱动中也需要实现这些 objects，否则 DRM 子系统无法正常运行。
drm_panel
drm_panel 不属于 objects 的范畴，它只是一堆回调函数的集合。但它的存在降低了 LCD 驱动与 encoder 驱动之间的耦合度。
为了解决该耦合的问题，DRM 子系统为开发人员提供了 drm_panel 结构体，该结构体封装了 connector & encoder 对 LCD 访问的常用接口。
于是，原来的 Encoder 驱动和 LCD 驱动之间的耦合，就转变成了上图中 Encoder 驱动与 drm_panel、drm_panel 与 LCD 驱动之间的“耦合”，从而实现了 Encoder 驱动与 LCD 驱动之间的解耦合。
小技巧：
为了方便驱动程序设计，通常都将 encoder 与 connector 放在同一个驱动中初始化，即 encoder 在哪，connector 就在哪。
如何抽象硬件
对于初学者来说，往往让他们迷惑的不是 DRM 中 objects 的概念，而是如何去建立这些 objects 与实际硬件的对应关系。因为并不是所有的 Display 硬件都能很好的对应上 plane/crtc/encoder/connector 这些 objects。下面我们就来一起学习，如何去抽象显示硬件到具体的 DRM object。
MIPI DSI 接口
下图为一个典型的 MIPI DSI 接口屏的硬件连接框图：
它在软件架构上与 DRM object 的对应关系如下图：
多余的细节不做介绍，这里只说明为何如此分配 drm object：
| object | 说明 |
|---|---|
| crtc | RGB timing的产生，以及显示数据的更新，都需要访问 Dislay Controller 硬件寄存器，因此放在 Display Controller 驱动中 |
| plane | 对 Overlay 硬件的抽象，同样需要访问 Display Controller 寄存器，因此也放在 Display Controller 驱动中 |
| encoder | 将 RGB 并行信号转换为 DSI 串行信号，需要配置 DSI 硬件寄存器，因此放在 DSI Controller 驱动中 |
| connector | 可以通过 drm_panel 来获取 LCD 的 mode 信息，但是 encoder 在哪，connector 就在哪，因此放在 DSI Controller 驱动中 |
| drm_panel | 用于获取 LCD mode 参数，并提供 LCD 休眠唤醒的回调接口，供 encoder 调用，因此放在 LCD 驱动中 |
驱动参考：https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
MIPI DPI 接口
DPI 接口也就是我们常说的 RGB 并行接口，Video 数据通过 RGB 并行总线传输，控制命令（如初始化、休眠、唤醒等）则通过 SPI/I2C 总线传输，比如早期的 S3C2440 SoC 平台。下图为一个典型的 MIPI DPI 接口屏的硬件连接框图：
该硬件连接在软件架构上与 DRM object 的对应关系如下图：
多余的细节不做介绍，这里只说明为何如此分配 drm object：
| object | 说明 |
|---|---|
| crtc | RGB timing的产生，以及显示数据的更新，都需要访问 LCD Controller 硬件寄存器，因此放在 LCD Controller 驱动中 |
| plane | LCDC 没有 Overlay 硬件，它只有一个数据源通道，被抽象为 Primary Plane，同样需要访问 LCDC 硬件寄存器，因此放在 LCDC 驱动中 |
| encoder | 由于 DPI 接口本身不需要对 RGB 信号做任何转换，因此没有哪个硬件与之对应。但是 drm objects 又缺一不可，因此实现了一个虚拟的 encoder object。至于为什么要放在 LCDC 驱动中实现，纯粹只是为了省事而已，你也可以放在一个虚拟的平台驱动中去实现该 encoder object。 |
| connector | encoder 在哪，connector 就在哪，没什么好说的了 |
| drm_panel | 用于获取 LCD mode 参数，并提供 LCD 休眠唤醒的回调接口，供 encoder 调用，因此放在 LCD 驱动中 |
驱动参考：https://elixir.bootlin.com/linux/v5.0/source/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
MIPI DBI 接口
DBI 接口也就是我们平时常说的 MCU 或 SPI 接口屏，这类屏的 VIDEO 数据和控制命令都是通过同一总线接口（I80、SPI接口）进行传输，而且这类屏幕必须内置 GRAM 显存，否则屏幕无法维持正常显示。
下图为一个典型的 DBI 接口屏的硬件连接框图：
该硬件连接在软件架构上与 DRM object 的对应关系如下：
上图参考 kernel4.19 tinydrm 软件架构。
| object | 说明 |
|---|---|
| crtc | 这类硬件本身不需要任何 RGB timing 信号，因此也没有实际的硬件与之对应。但是 drm objects 缺一不可，需要实现一个虚拟的 crtc object。由于更新图像数据的动作需要通过 SPI 总线发送命令才能完成，因此放在了 LCD 驱动中 |
| plane | 没有实际的硬件与之对应，但 crtc 初始化时需要一个 plane object 作为参数传递，因此和 crtc 放在一起 |
| encoder | 没有实际的硬件与之对应，使用虚拟的 encoder object。因为这类硬件并不是将 RGB 信号转换为 SPI 信号，而是根本就没有 RGB 信号源，也就无从谈起 encoder 设备。但是为了通知 LCD 休眠唤醒，需要调用 LCD 驱动的相应接口，因此放在 LCD 驱动中 |
| connector | 由于没有了 drm_panel，需要调用 LCD 接口来获取 mode 参数，因此放在 LCD 驱动中 |
驱动参考：https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tinydrm/ili9341.c
总结
- 这 7 个 objects 缺一不可
- framebuffer 只是负责描述显存信息，gem 则负责显存的分配/释放等操作
- encoder 在哪里，connector 就在哪里
在下一篇文章中，我们将开始真正动手编写一个《最简单的 DRM 驱动程序》，尽情期待！
往期回顾：
DRM (Direct Rendering Manager) 学习简介
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/176266.html原文链接：https://javaforall.net
