第一章 MMIO 的本质

1.1 什么是 MMIO

在 Linux 驱动开发过程中，CPU 控制硬件最直接的方式就是访问设备寄存器。对于 UART、GPIO、SPI、I2C、CAN、Ethernet 等控制器而言，其内部状态、配置参数以及数据收发功能最终都通过寄存器完成管理。所谓 MMIO（Memory Mapped I/O，内存映射输入输出），本质上是将设备寄存器映射到 CPU 地址空间，使 CPU 可以像访问内存一样访问硬件设备，而无需使用专门的 I/O 指令。

现代 ARM、RISC-V 等嵌入式处理器几乎全部采用 MMIO 机制。例如 RK3568 的 UART 控制器可能位于 0xFE660000，CAN 控制器位于 0xFE570000，这些地址虽然看起来像内存地址，但实际上对应的是外设寄存器区域。当 CPU 执行读写操作时，请求会通过总线到达对应硬件模块，从而实现对设备的控制。

1.2 MMIO 与普通内存的区别

从程序角度观察，MMIO 区域和普通内存都表现为地址空间的一部分，因此很多寄存器访问代码看起来与内存操作没有区别。但从硬件角度看，两者存在本质差异。普通内存用于存储数据，读写内容通常不会产生额外动作，而寄存器访问往往会触发硬件行为，例如启动发送、清除中断、复位模块或者改变工作模式。

由于寄存器具有副作用，因此 MMIO 区域不能完全按照普通内存方式处理。CPU 对普通内存进行缓存、预取或者乱序执行通常不会产生问题，但如果这些优化作用于设备寄存器，则可能导致驱动看到错误状态甚至破坏设备时序。因此 Linux 专门为 MMIO 提供独立访问框架，以保证寄存器访问的正确性和一致性。

第二章 从总线角度理解 MMIO

2.1 CPU 如何访问设备寄存器

当驱动执行一次寄存器读取操作时，CPU 实际发出的是一次总线访问请求。对于 SoC 而言，内部通常包含 AXI、AHB 或 APB 等总线结构，各种外设控制器挂接在总线之上。当访问地址落入某个设备地址范围时，总线仲裁逻辑会将请求转发给对应控制器，从而完成寄存器访问。

例如 CAN 控制器地址范围为 0xFE570000～0xFE570FFF，当 CPU 读取该区域地址时，请求最终会被路由到 CAN 模块。控制器接收到访问请求后返回寄存器内容，再通过总线传递回 CPU。整个过程虽然表现为一次普通内存读取，但底层实际上经历了完整的总线事务过程。

2.2 地址空间的划分方式

现代 SoC 通常将整个物理地址空间划分为多个区域，包括 DDR、SRAM、BootROM、寄存器区域以及外设控制器区域。CPU 在访问地址时并不关心具体目标设备，而是由地址译码单元根据访问地址决定最终访问对象，这也是统一地址空间模型能够工作的基础。

对于驱动开发者而言，设备手册中的寄存器基地址实际上就是总线地址映射结果。例如 GPIO、UART、SPI 等模块都拥有独立地址范围，只要访问落入对应区域，硬件便能够识别目标设备。因此 MMIO 的核心思想就是利用统一地址空间完成设备访问，而无需额外设计复杂的 I/O 指令体系。

第三章 Linux 中的 MMIO 映射

3.1 为什么需要 ioremap

虽然设备寄存器拥有固定物理地址，但 Linux 内核运行在虚拟地址空间之中。CPU 实际访问的是虚拟地址，而不是 SoC 手册中的物理地址，因此驱动无法直接使用物理地址访问寄存器。为了让 MMU 能够正确完成地址转换，内核必须先建立从虚拟地址到设备物理地址的映射关系。

ioremap 的作用正是完成这种映射。当驱动传入寄存器物理地址和长度后，内核会申请虚拟地址区域并建立页表项，最终返回一个新的虚拟地址。后续所有寄存器访问都通过该地址完成，而 MMU 则负责自动将其转换到目标设备寄存器区域。

3.2 MMIO 映射后的访问流程

驱动调用 ioremap 获得地址后，看到的是一个普通指针，但底层已经具备完整页表映射关系。当 CPU 执行寄存器读写时，MMU 首先查询页表获取对应物理地址，然后将访问请求发送至总线，最终由目标控制器完成寄存器访问并返回结果。

整个过程中驱动无需感知 MMU、页表或总线细节，只需要保存映射地址即可完成硬件控制。这种分层设计将驱动逻辑与硬件地址管理解耦，使 Linux 能够在不同处理器架构和不同 SoC 平台之间保持统一的驱动开发模式。

第四章 readl 与 writel

4.1 为什么不能直接解引用

许多初学者在看到 MMIO 地址后，会尝试通过强制类型转换直接访问寄存器，例如使用指针读写映射地址。从语法角度看这种方式能够工作，但它绕过了 Linux 提供的寄存器访问框架，可能导致编译器优化、CPU 重排序或者平台兼容性问题。

Linux 提供 readb、readw、readl 以及对应的 write 接口，目的就是统一寄存器访问行为。这些接口内部会根据体系结构特点处理必要的同步和屏障操作，保证设备寄存器访问严格符合驱动预期，因此主线驱动代码几乎全部采用标准接口完成寄存器操作。

4.2 寄存器访问顺序的重要性

很多硬件模块要求寄存器按照固定顺序访问。例如初始化 UART 时需要先配置波特率，再开启发送器和接收器；初始化 CAN 控制器时需要先进入配置模式，再设置波特率参数，最后启动控制器。如果访问顺序被打乱，设备可能进入异常状态。

现代 CPU 为提高执行效率，会主动进行乱序执行和流水线优化。如果没有合适的同步机制，寄存器访问顺序可能与代码顺序不同。Linux 的寄存器访问接口通过屏障机制限制这种优化行为，确保配置寄存器、状态寄存器和控制寄存器按照驱动要求顺序执行。

第五章 MMIO 与缓存机制

5.1 为什么设备寄存器不能缓存

普通内存的访问速度远低于 CPU，因此引入 Cache 可以显著提高性能。但设备寄存器的目标并非存储数据，而是反映硬件实时状态。如果 CPU 缓存了寄存器内容，那么驱动读取到的数据可能已经过时，导致状态判断出现错误。

例如网卡接收完成后会更新状态寄存器，如果 CPU 一直读取缓存副本，则驱动可能永远无法发现新的数据到达。同样，向控制寄存器写入启动命令后，如果数据停留在缓存而未真正写入设备，那么硬件也不会执行对应动作。因此 MMIO 区域通常被配置为不可缓存属性。

5.2 Device Memory 属性

ARM64 架构页表支持多种内存属性，其中 Device Memory 专门用于寄存器区域。与 Normal Memory 不同，Device Memory 禁止缓存、禁止预取，同时严格限制访问重排序行为，从而保证 CPU 对寄存器的访问能够真实、及时地到达硬件设备。

Linux 在执行 ioremap 时会自动设置合适的页属性，因此驱动开发者通常无需手工处理缓存问题。但理解 Device Memory 的工作机制仍然十分重要，因为很多驱动故障最终都与错误的内存属性或者不正确的访问方式有关。

第六章 MMIO 在驱动中的应用

6.1 GPIO 驱动中的寄存器控制

GPIO 控制器本质上是一组寄存器集合，方向配置、输入状态和输出电平都由不同寄存器管理。驱动完成 ioremap 后，通过读取状态寄存器获取引脚电平，通过写入控制寄存器改变输出状态，从而实现对外部设备的控制。

从驱动框架角度看，GPIO 子系统只是对底层寄存器进行了进一步封装。无论是 gpiod_set_value() 还是 gpiod_get_value()，最终都会转化为 MMIO 寄存器访问，因此理解 MMIO 实际上也是理解 GPIO 驱动实现机制的重要基础。

6.2 CAN 与 UART 驱动中的 MMIO

CAN 和 UART 控制器同样依赖大量寄存器完成工作。例如发送数据时，驱动需要将数据写入发送缓冲寄存器，然后设置发送控制位启动硬件；接收数据时，则通过状态寄存器判断数据是否到达，再从接收缓冲寄存器读取数据内容。

对于这类通信控制器而言，几乎所有功能最终都表现为 MMIO 操作。Linux 网络子系统、TTY 子系统虽然提供了统一接口，但底层驱动仍然依赖 readl 和 writel 与硬件交互，因此 MMIO 是整个设备驱动体系最基础的组成部分之一。

第七章 MMIO 设计思想

7.1 Linux 如何抽象硬件访问

从设备树描述硬件资源，到 Platform Driver 获取资源信息，再到 ioremap 建立映射、readl 和 writel 完成寄存器访问，Linux 构建了一套完整的硬件抽象体系。驱动开发者无需关心具体总线实现，也无需管理复杂页表结构，只需按照统一接口访问设备即可。

这种抽象极大提高了驱动可移植性。同一套驱动代码能够运行在不同 ARM SoC、RISC-V 平台甚至部分 x86 嵌入式设备上，而底层 MMIO 映射和寄存器访问细节则由内核负责处理，从而降低了驱动开发复杂度。

7.2 从 MMIO 理解驱动架构

很多 Linux 子系统看似复杂，但如果向下追踪最终都会回到 MMIO 层面。无论是网络设备、串口设备、存储控制器还是工业总线设备，其核心任务都是通过寄存器控制硬件行为，因此 MMIO 可以被视为驱动与硬件之间最直接的连接通道。

理解 MMIO 后，再学习 GPIO、UART、SPI、I2C、CAN 或 PCIe 驱动会容易很多，因为这些驱动的本质区别往往只是寄存器定义不同，而访问方式基本一致。从某种意义上说，掌握 MMIO 就等于掌握了 Linux 驱动控制硬件的底层语言。