[TOC]

Qcom DRM显示驱动架构

DRM原为Linux下的图形渲染架构(Direct Rendering Manager), 是device-independent内核级别驱动，内核提供直接访问硬件的权限， 原本是设计提供给PC使用来支持复杂的图形设备，后来也用于嵌入式系统上。而我们所属的的DRM，还包括KMS。

DRM/KMS概述

• 引入直接渲染管理器 (DRM) 来处理嵌入 GPU 的显卡
• 内核模式设置 (KMS) 是 DRM API 的一部分,可在给定的显示上设置模式
• 渲染和模式设置分为两个不同的 API,可以通过 /dev/dri/renderX 和 /dev/dri/controlDX 访问
• KMS 提供了一种配置显卡(或嵌入式系统)的显示管道的方法
• KMS 可替代帧缓冲区 dev (FBDEV)

功能	FBDev	DRM/KMS
上游	减少主动维护 不会提供所有功能(如叠加、游标) 现在鼓励开发人员迁移到 DRM/KMS	通过开放源代码进行主动维护 更好地控制显示管道 图形 – 显示协议采用应用广泛的标准化架构 全套高级功能
用户/内核 API	自定义叠加/原子提交 API	标准(内核上游)API
源管道管理	通过枚举索引和原子提交 IOCTL 进行管理 通过 DPU 驱动程序功能公开的功能	通过属性和原子模式设置提交管理的平面对象 通过平面属性公开的功能
层混合器管理	在驱动程序中处理,用户模式下难以了解当前动态	驱动程序中的默认分配。用户模式可以查询和覆盖,虚拟化在 CRTC 中得到处理
面板管理	通过多个 sysfs 节点进行管理	通过连接器对象属性进行管理

DRM/KMS构成

先来看一个图：

DRM-KMS组成

• 帧缓冲区 (struct drm_framebuffer)
  帧缓冲区是抽象的内存对象,可提供一个扫描输出到 CRTC 的像素源。实现取决于使用的内存管理器和 IOMMU 功能。

• 平面 (struct drm_pane)
  一个平面代表一个图像源,可以在扫描输出过程中与 CRTC 混合或叠加在 CRTC 之上。
  平面与帧缓冲区相关联,以裁剪映像内存(源)的一部分,并选择将其缩放到目标尺寸。最终会与 CRTC 混合或叠加在 CRTC 之上。

• CRTC (struct drm_crtc)
  CRT 控制器 (CRTC) 不只与 CRT 显示有关,它还能配置适当的显示设置:显示计时/分辨率,将帧缓冲内容扫描输出到一个或多个显示等等。

• 编码器 (struct drm_encoder)
  从 CRTC 获取像素数据并将其转换为适合任何已连接的连接器的格式。

• 连接器 (struct drm_connector)
  表示显示接口(HDMI、DisplayPort、DSI、VGA),将信号传输到显示,检测显示,曝光模式等。

• 桥接器
  与编码器相关联,参与模式设置,设备电源管理,连接检测等。

高通HAL层实现

HAL实现，采用了Device和Resource分离的方式，Resource采用了私有库封装，看不了代码。Device又采用了3层接口设计，第一层HWCDisplay和Session强相关，也就是和Android系统强相关，第二层DisplayInterface是HWC的逻辑层，第三层HWInterface是和底层的驱动实现相关。

高通HWC HAL相关类图

目前高通，HWInterface分为两种实现，一种直接基于FB驱动实现，另外一种也是目前在用的，基于DRM驱动架构实现。

DRM抽象了DRMManager进行管理，抽象的DRMConnectorManager，DRMCrtcManager，DRMConnectorManager，DRMPlaneManager和前面所说的DRM/KMS的组成对应。

所以，对整个显示流程来说，数据流是这样的：

Android DRM显示数据流图

小结

这里只是概要性的讲了一下DRM显示。不破戒了，后续更新！