2. 原子模式设置(Atomic Modeset)核心概念：原子性、事务性、状态对象(State Objects)
原子模式设置（Atomic Modeset）是 DRM 子系统自 Linux 4.x 内核起引入的显示配置框架，旨在解决传统 Legacy Modeset 接口中“中间状态可见、配置顺序依赖、回滚困难”等固有问题。本章将深入剖析原子提交的三大核心支柱：原子性、事务性与状态对象，为后续学习原子提交 API 调用链奠定理论基础。
学习提示：原子模式设置并非简单的 API 升级，而是一种“全有或全无”的显示状态管理哲学。理解这三个概念，就等于掌握了现代 DRM 驱动设计的钥匙。
2.1 原子性（Atomicity）
原子性保证一次显示配置更新要么全部成功应用，要么完全不生效，不存在中间状态被硬件或用户空间观察到的情况。在传统模式下，逐个更新 CRTC、Plane、Connector 属性时，屏幕可能出现撕裂、闪烁或短暂黑屏——这些正是原子性缺失的典型表现。
关键特性：
- 全有或全无：提交的配置变更作为一个不可分割的整体执行。
- 无中间状态：硬件不会停留在部分更新的过渡状态。
- 隐式序列化：内核自动保证多个属性更新之间的依赖关系正确。
2.2 事务性（Transactional）
原子提交遵循严格的事务模型，包含“开始事务 → 校验 → 提交 → 提交完成”四个阶段。事务性保证了在复杂多对象配置场景下，驱动能够预演所有变更，并在发现冲突时优雅回滚。
| 阶段 | 操作 | 回调函数 | 说明 |
|---|---|---|---|
| 1. 开始事务 | 分配状态对象 | atomic_duplicate_state() |
为每个 CRTC/Plane/Connector 创建影子状态副本 |
| 2. 校验 | 检查配置合法性 | atomic_check() |
验证带宽、时钟、资源冲突等约束条件 |
| 3. 提交 | 应用配置到硬件 | atomic_commit() |
在 VBlank 中断中执行硬件寄存器写入 |
| 4. 提交完成 | 清理与通知 | atomic_flush() |
释放旧状态、发送 VBlank 事件给用户空间 |
避坑指南：事务校验阶段（atomic_check）是驱动开发者最容易出错的地方。常见问题包括：未正确计算带宽需求、遗漏 CRTC-Plane 关联约束、以及忽略 Connector 的物理连接状态。务必在 atomic_check 中覆盖所有硬件约束。
2.3 状态对象（State Objects）
状态对象是原子模式设置的核心数据结构。每个 DRM 对象（CRTC、Plane、Connector）都对应一个“状态对象”，用于保存该对象的全部可配置属性。原子提交的本质就是：创建一组新的状态对象 → 修改属性 → 校验 → 一次性替换到硬件。
2.3.1 核心状态对象类型
| 状态对象 | 对应 DRM 对象 | 关键属性 | 数据结构 |
|---|---|---|---|
| CRTC 状态 | drm_crtc |
模式、使能、Gamma、CTM | drm_crtc_state |
| Plane 状态 | drm_plane |
帧缓冲、裁剪、旋转、Alpha | drm_plane_state |
| Connector 状态 | drm_connector |
连接状态、链路参数、HDCP | drm_connector_state |
| 全局状态 | — | 共享资源、带宽预算 | drm_atomic_state |
2.3.2 状态对象的生命周期
- 创建（Duplicate）：调用
atomic_duplicate_state()从当前状态深拷贝一份影子状态。 - 修改（Modify）：用户空间通过
drm_atomic_set_property()或驱动内部直接修改影子状态的属性字段。 - 校验（Check）：驱动实现
atomic_check()回调，遍历所有影子状态，验证硬件约束。 - 提交（Commit）：校验通过后，影子状态被“交换”为当前状态，硬件开始应用新配置。
- 销毁（Destroy）：旧状态被放入 RCU 回写队列，等待所有硬件操作完成后释放。
核心代码模式：驱动开发者需要实现的关键回调函数签名如下：
// 状态复制
struct drm_crtc_state *(*atomic_duplicate_state)(struct drm_crtc *crtc);
// 状态校验
int (*atomic_check)(struct drm_device *dev, struct drm_atomic_state *state);
// 状态提交（异步）
void (*atomic_commit)(struct drm_device *dev,
struct drm_atomic_state *state,
bool nonblock);
// 状态销毁
void (*atomic_destroy_state)(struct drm_device *dev,
struct drm_crtc_state *state);2.4 原子性、事务性、状态对象的协同关系
三个概念并非孤立存在，而是构成一个完整的显示配置管理体系：
- 状态对象是“数据载体”，保存每个硬件对象的配置快照。
- 事务性是“流程引擎”，定义状态对象从创建到销毁的完整生命周期。
- 原子性是“质量保证”，确保事务提交的结果是确定且无副作用的。
理解口诀：“状态对象装数据，事务流程管生命周期，原子性保结果一致”——三者缺一不可，共同构成现代 DRM 显示驱动的基石。
2.5 与传统模式设置的关键差异
| 对比维度 | 传统模式设置（Legacy） | 原子模式设置（Atomic） |
|---|---|---|
| 更新粒度 | 逐个对象独立更新 | 批量事务统一更新 |
| 中间状态 | 存在，用户空间可见 | 不存在，硬件切换瞬间完成 |
| 校验时机 | 每个属性设置时独立校验 | 事务提交前统一校验 |
| 回滚能力 | 无，部分更新后无法撤销 | 校验失败自动回滚 |
| 状态管理 | 直接修改硬件寄存器 | 影子状态 → 校验 → 硬件切换 |
| 并发安全 | 依赖用户空间互斥 | 内核态 RCU + 锁机制保证 |
| VBlank 同步 | 可选，非强制 | 强制在 VBlank 边界切换 |
迁移注意事项：从传统模式迁移到原子模式时，驱动开发者需要特别注意：
1. 必须实现
2. 所有硬件约束必须在校验阶段检查，不要在提交阶段才报错。
3. 状态对象的引用计数管理要谨慎，避免内存泄漏或 UAF（Use-After-Free）。
4. 建议先实现
1. 必须实现
atomic_check() 回调，不能留空。2. 所有硬件约束必须在校验阶段检查，不要在提交阶段才报错。
3. 状态对象的引用计数管理要谨慎，避免内存泄漏或 UAF（Use-After-Free）。
4. 建议先实现
DRIVER_ATOMIC 标志位，逐步替换 Legacy 接口。