Arm 连贯地理解DMA和总线方面的软硬件交互

我已经对基于ARM的主板中涉及一般DMA事务的几个组件（包括软件和硬件）积累了一定程度的知识，但我不明白它们是如何完美集成的，我没有找到关于这方面的完整连贯的描述

我会写下我已经掌握的高水平知识，我希望有人能纠正我的错误，并完成缺失的部分，这样整个画面就会清晰。我的描述从用户空间软件开始，深入到硬件组件。被误解的部分采用斜体加粗格式

• 用户模式应用程序请求从某个设备进行读/写操作，即进行i/O操作
• 操作系统接收到请求并将其交给相应的驱动程序（每个操作系统都有自己的机制来执行此操作，我不需要在此进一步深入了解，但如果您想在此处分享见解，欢迎您）
• 负责处理I/O请求的驱动程序必须知道设备映射到的地址（因为我对基于ARM的板感兴趣，所以这里只有内存映射I/O，没有端口I/O）。在大多数情况下（如果我们考虑像智能手机一样的板），有一个Linux内核解析从设备树的设备地址，该设备树是在引导时间（现代方法）从引导装载器提供的，或者Linux是为特定的模型家族预先编译的，并且在其内部有设备地址（在其源代码中硬编码）。（采用陈旧过时的方法）。在某些情况下（在智能手机中经常发生），部分驱动程序是预编译的，只是打包到内核中，即它们的源代码是关闭的，因此，与设备相对应的地址是未知的正确吗？
• 假设驱动程序知道它想要与之通信的设备的相关寄存器的地址，它将分配一个缓冲区（通常在内核空间中），设备将在DMA的帮助下向该缓冲区写入数据。驱动程序需要通知设备该缓冲区的位置，但设备使用的地址（操作内存）与驱动程序（cpu）使用的地址不同，因此，驱动程序需要通知设备其刚刚分配的缓冲区的“总线地址”驱动程序如何通知设备该地址？使用IOMMU的流行程度如何？使用IOMMU时，是有一个硬件组件管理寻址还是每个设备一个？
• 然后，驱动程序命令设备执行其工作（通过操作其寄存器），设备将输出数据直接传输到内存中分配的缓冲区这里我对设备驱动程序：总线：总线控制器：实际设备之间的关系有点困惑。例如，某个虚拟设备知道以I2C协议进行通信；SoC指定了一个I2C总线接口-这实际上是什么？I2C总线是否有某种总线控制器？cpu是与I2C总线接口通信还是直接与设备通信？（即I2C总线接口是无缝的）。我想有一些设备驱动程序经验的人可以很容易地回答这个问题。
• 该设备填充DMA通道。由于设备不是直接连接到内存，而是通过某条总线连接到DMA控制器（该控制器控制总线），因此它与DMA交互，将所需数据传输到内存中分配的缓冲区。当线路板供应商使用ARM IP核和总线规范时，此步骤涉及通过AMBA规范（即AHB/多AHB/AXI）的总线进行的交易，以及设备和其上的DMAC之间的某些协议我想知道更多关于这一步的信息，到底发生了什么？ARM的DMA控制器有很多规格，哪一种比较流行？哪个是过时的？
• 当设备完成时，它发送一个中断，该中断通过中断控制器传输到操作系统，操作系统的中断处理程序将其定向到适当的驱动程序，该驱动程序现在知道DMA传输已完成

---

这里您稍微混淆了两件事-有些设备（例如UART、MMC控制器、音频控制器，通常是较低带宽的设备）依赖于外部DMA控制器（“Linux术语中的DMA引擎”），但许多设备本身就是总线主控器，直接执行自己的DMA（例如，GPU、USB主机控制器，当然还有DMA控制器本身）。前者涉及到CPU编程DMA控制器的一系列额外复杂性，所以我将忽略它，只考虑直接总线主DMA。 在典型的ARM SoC中，CPU集群和其他主外设、内存控制器和其他从外设都通过各种AMBA互连连接在一起，形成一个“总线”（通常都映射到Linux中的“平台总线”），其中主设备根据互连的地址映射对从设备进行寻址。您可以安全地假设设备驱动程序知道（通过设备树或硬编码）设备在CPU的物理地址映射中出现的位置，否则它们将毫无用处

在较简单的系统上，有一个单一的地址映射，因此CPU用于寻址RAM和外围设备的物理地址可以作为DMA地址与其他主机自由共享。其他系统更复杂，其中一个更为著名的是，CPU和GPU具有不同的地址映射；例如，互连是硬连接的，因此当GPU在“总线地址”0x7e000000处看到外围设备时，CPU在“物理地址”0x20000000处看到外围设备。此外，在具有40位物理地址的LPAE系统中，互连可能需要为不同的主机提供不同的视图，例如在