DRM 驱动程序开发（开篇）

前言

在前面的《最简单的DRM应用程序》系列文章中，我们学习了如何使用 libdrm 接口编写 DRM 应用程序。从本篇开始，我们将进入一个全新的世界，一起来学习如何在 kernel 空间编写 DRM 驱动程序。

Objects

在开始编写 DRM 驱动程序之前，我有必要对 DRM 内部的 Objects 进行一番介绍。因为这些 Objects 是 DRM 框架的核心，它们缺一不可。

图片3.png-17.2kB

上图蓝色部分则是对物理硬件的抽象，黄色部分则是对软件的抽象。虚线以上的为 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 之间的关系：

图片2.png-20.7kB

通过上图可以看到，plane 是连接 framebuffer 和 crtc 的纽带，而 encoder 则是连接 crtc 和 connector 的纽带。与物理 buffer 直接打交道的是 gem 而不是 framebuffer。

需要注意的是，上图蓝色部分即使没有实际的硬件与之对应，在软件驱动中也需要实现这些 objects，否则 DRM 子系统无法正常运行。

drm_panel

drm_panel 不属于 objects 的范畴，它只是一堆回调函数的集合。但它的存在降低了 LCD 驱动与 encoder 驱动之间的耦合度。

图片3.png-9.2kB

耦合的产生：
（1）connector 的主要作用就是获取显示参数，所以会在 LCD 驱动中去构造 connector object。但是 connector 初始化时需要 attach 上一个 encoder object，而这个 encoder object 往往是在另一个硬件驱动中生成的，为了访问该 encoder object，势必会产生一部分耦合的代码。
（2）encoder 除了扮演信号转换的角色，还担任着通知显示设备休眠唤醒的角色。因此，当 encoder 通知 LCD 驱动执行相应的 enable/disable 操作时，就一定会调用 LCD 驱动导出的全局函数，这也必然会产生一部分的耦合代码。

为了解决该耦合的问题，DRM 子系统为开发人员提供了 drm_panel 结构体，该结构体封装了 connector & encoder 对 LCD 访问的常用接口。

图片4.png-10.2kB

于是，原来的 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 接口屏的硬件连接框图：

图片5.png-15.3kB

它在软件架构上与 DRM object 的对应关系如下图：

图片10.png-46.8kB

多余的细节不做介绍，这里只说明为何如此分配 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 接口屏的硬件连接框图：

图片8.png-14.3kB

该硬件连接在软件架构上与 DRM object 的对应关系如下图：

图片1.png-26.1kB

多余的细节不做介绍，这里只说明为何如此分配 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 接口屏的硬件连接框图：

图片9.png-9.8kB

该硬件连接在软件架构上与 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 驱动中