linux drm子设备号,Linux DRM (三) RK 平台 DRM 代码分析 · Rockchip

本篇是 DRM 的第三篇文章。

在 《Linux DRM (一) Display Server》 中我们了解了 DRM 诞生的历史。

在 《Linux DRM (二) 基本概念和特性》 中我们了解了一些基本的概念。

现在，我们终于要向 DRM 源码进军了。

+

一、概览

不知大家是否还记得，之前我有引用 Wiki 中对 DRM 的介绍，这里我们再回顾一下：

DRM 由两个部分组成：

一是 Kernel 的子系统，这个子系统对硬件 GPU 操作进行了一层框架封装。

二是 提供了一个 libdrm 库，里面封装了一系列 API，用来进行图像显示。

整体来看和 Android 上所采用的 Direct Frame Buffer 差不多。

Android Kernel 走的是 FB 的框架，并在 HAL 抽象出一个 FBDEV，来进行 FB IOCTL 统一管理。

DRM 就相当于直接对图形设备集中处理，并且多出了一个 libdrm 库。

+

其整体脉络如下：

+

源码文件

component framework

在讲述启动过程之前，先简单了解一下 component framework。

+

因为 drm下挂了许多的设备, 启动顺序经常会引发各种问题:

+一个驱动完全有可能因为等另一个资源的准备, 而probe deferral, 导致顺序不定

子设备没有加载好, 主设备就加载了, 导致设备无法工作

子设备相互之间可能有时序关系,不定的加载顺序,可能带来有些时候设备能工作,有些时候又不能工作

现在编kernel是多线程编译的,编译的前后顺序也会影响驱动的加载顺序.

这时就需要有一个统一管理的机制, 将所有设备统合起来, 按照一个统一的顺序加载,

Display-subsystem正是用来解决这个问题的, 依赖于component的驱动, 通过这个驱动,

可以把所有的设备以组件的形式加在一起, 等所有的组件加载完毕后, 统一进行bind/unbind.

+

代码路径 drivers/base/component.c

+

以下为rockchip drm master probe阶段component 主要逻辑, 为了减小篇幅, 去掉了无关的代码:

+static int rockchip_drm_platform_probe(struct platform_device *pdev)

{

for (i = 0;; i++) {

/* ports指向了vop的设备节点 */

port = of_parse_phandle(np, "ports", i);

component_match_add(dev, &match, compare_of, port->parent);

}

for (i = 0;; i++) {

port = of_parse_phandle(np, "ports", i);

/* 搜查port下的各个endpoint, 将它们也加入到match列表 */

rockchip_add_endpoints(dev, &match, port);

}

return component_master_add_with_match(dev, &rockchip_drm_ops, match);

}

static void rockchip_a