Linux DMA技术(三)DMA引擎

大家好，我是小志。我们的口号是：学习、成长、应对未来风险。 

书接上回---

DMA-内核框架

 DMA引擎用于开发DMA控制器驱动程序，是一个通用的内核框架，这个框架使得客户驱动程序即从设备能够请求并使用DMA通道从控制器发起DMA传输。

DMA引擎框架是Linux内核为统一管理所有DMA控制器（包括Soc全局DMA，从设备DMA引擎）而设计的标准化软件层。 头文件如下： 

#include<linux/dmaengine.h>

流程如下：

（1）通知内核关于设备的DMA寻址能力。

struct dma_device 代表一个具体的dma控制器，框架通过它记录DMA的硬件特征（寻址范围，支持的传输类型，通道数），外设驱动通过它告知内核该DMA访问哪些地址

（2）向一个DMA通道发出请求。

struct dma_chan 代表DMA控制器的物理通道，外设驱动调用dma_request_channel()向框架申请通道，框架负责分配空闲通道

（3）如果成功，配置这个DMA通道。

struct dma_set_* 框架提供统一API（比如设置传输方向、地址对齐、DMA模式），底层自动转换成对应DMA控制器的寄存器配置

（4）准备或配置DMA传输。这一步将返回表示DMA传输的传输描述符。

struct dma_async_tx_descriptor 框架返回的传输任务描述符，封装了本次传输所有的信息，SG表，传输长度，方向，回调函数

（5）使用传输描述符提交DMA传输。然后将DMA传输添加到与指定通道相对应的控制器挂起队列中。这一步将返回一个特殊的cookie，你可以用它来检查DMA活动的进展情况。

dma_cookie_t 提交描述符后框架返回的“任务ID”，外设驱动可以用这个cookie查询传输状态，取消传输，提交后框架会把描述符加入DMA控制器的挂起队列

（6）在指定的通道上开始DMA传输，以便在该通道空闲时启动控制器挂起队列中的第一个DMA传输。

dma_async_issue_pending() 框架调用该接口后，DMA控制器会检查通道是否空闲，若空闲立即执行挂起队列中的第一个传输任务，若忙则等待当前传输完成后自动执行

DMA控制器接口

控制器执行内存传输（无须CPU干预），通道则是客户端驱动程序（支持DMA的驱动程序）向控制器提交作业的方式。DMA控制器被抽象为struct dma_device结构体实例。DMA控制器在Linux内核中被抽象为dma_device结构体实例。就其本身而言，控制器在没有客户端的情况下是没有用的，这是因为客户端会使用控制器所暴露的通道；而且控制器驱动程序必须暴露回调函数给通道，用于通道配置。dma_device结构体定义如下：

struct dma_device {    unsigned int chancnt;    unsigned int privatecnt;    struct list_head channels;    struct list_head global_node;    struct dma_filter filter;    dma_cap_mask_t cap_mask;    u32 src_addr_widths;    u32 dst_addr_widths;    u32 directions;    int (*device_alloc_chan_resources)(struct dma_chan *chan);    void (*device_free_chan_resources)(struct dma_chan *chan);    struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(        struct dma_chan *chan, dma_addr_t dst,        dma_addr_t src, size_t len, unsigned long flags);    struct dma_async_tx_descriptor *(*device_prep_dma_memset)(        struct dma_chan *chan, dma_addr_t dest, int value,        size_t len, unsigned long flags);    struct dma_async_tx_descriptor *(*device_prep_dma_memset_sg)(        struct dma_chan *chan, struct scatterlist *sg,        unsigned int nents, int value,        unsigned long flags);    struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(        struct dma_chan *chan, unsigned long flags);    struct dma_async_tx_descriptor *(*device_prep_slave_sg)(        struct dma_chan *chan, struct scatterlist *sgl,        unsigned int sg_len,        enum dma_transfer_direction direction,        unsigned long flags, void *context);    struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(        struct dma_chan *chan, dma_addr_t buf_addr,        size_t buf_len, size_t period_len,        enum dma_transfer_direction direction,        unsigned long flags);    void (*device_caps)(struct dma_chan *chan, struct dma_slave_caps *caps);    int (*device_config)(struct dma_chan *chan, struct dma_slave_config *config);    void (*device_synchronize)(struct dma_chan *chan);    enumdma_status(*device_tx_status)(        struct dma_chan *chan, dma_cookie_t cookie,        struct dma_tx_state *txstate);    void (*device_issue_pending)(struct dma_chan *chan);    void (*device_release)(struct dma_device *dev);};

chancnt：指定控制器支持多少个DMA通道channels：struct dma_chan数据结构链表，对应于控制器所暴露的DMA通道。privatecnt：表示dma_request_channel()函数请求了多少个DMA通道，该函数是用于请求DMA通道的DMA引擎APIcap_mask：一个或多个dma_capability标志，代表控制器能力，他的取值如下：

enum dma_transaction_type {    DMA_MEMCPY,		/* Memory to memory copy */    DMA_XOR,		/* Memory to memory XOR */    DMA_PQ,		/* Memory to memory P+Q computation */    DMA_XOR_VAL,	/* Memory buffer parity check using XOR */    DMA_PQ_VAL,	        /* Memory buffer parity check using P+Q */    DMA_INTERRUPT,	/* The device can generate dummy transfer that will generate                         * interrupts */    DMA_MEMSET_SG,	/* Prepares a memset operation over a scatter list */    DMA_SLAVE,		/* Slave DMA operation, either to or from a device */    DMA_PRIVATE,	/* channels are not to be used                         * for global memcpy. Usually used with DMA_SLAVE */    DMA_CYCLIC,		/* can handle cyclic tranfers */    DMA_INTERLEAVE,	/* Memory to memory interleaved transfer */};

· DMA_XFER_UNSPEC 未指定 / 未知的传输类型（默认 / 占位值） 用于初始化、兼容性适配，驱动实际使用时需替换为具体类型（如 DMA_SLAVE）；

· DMA_MEMCPY 内存→内存的纯内存 DMA 传输（无外设参与） SoC 全局 DMA 控制器的内存缓冲区高速拷贝（如把 wbuf 数据拷贝到 wbuf2）；

· DMA_SLAVE 从设备（外设）↔ 系统内存的 DMA 传输（最核心！） 你代码中的 SDMA 传输（SD 卡 ↔ 内存）、UART/SPI 外设 ↔ 内存传输、网卡 ↔ 内存数据包传输；是从设备 DMA 引擎的标配类型，支持单向（读 / 写）或双向传输；

· DMA_CYCLIC 循环 DMA 传输（环形缓冲区↔外设） 音频设备（I2S）持续音频流传输、ADC/DAC 连续采样 / 输出、CAN 总线持续数据收发；

· DMA_INTERLEAVE 交错 DMA 传输（多组数据按规则交织） 视频设备（YUV 数据交错传输）、多通道 ADC 采样数据交错接收、多媒体外设的交织数据流；

· DMA_PRIVATE DMA 控制器私有传输（不对外暴露） DMA 控制器自身硬件初始化 / 配置，驱动层几乎不用；

· DMA_ASYNC_TX 异步事务 DMA 传输（结合 async_tx 框架） 带硬件加速的场景（如网卡数据校验和计算、加密芯片的 DMA 加解密）；

· DMA_INTERLEAVE 多组数据按硬件级规则交错传输（地址 / 长度 / 通道交错），而非连续传输

· DMA_XOR DMA 控制器硬件加速执行 XOR（异或）计算，边传输数据边完成校验（替代 CPU 计算）（异或）计算，边传输数据边完成校验（替代 CPU 计算）

· DMA_PQ DMA 硬件加速执行 PQ（Reed-Solomon 奇偶校验）计算（RAID 6 核心算法），边传输边校验

· DMA_XOR_VAL DMA 硬件基于预设 XOR 校验值，验证传输数据的完整性（对比计算结果与预设值）

· DMA_PQ_VAL DMA 硬件验证 PQ 校验值是否匹配（RAID 6 数据读取完整性校验）

· DMA_MEMSET_SG DMA 硬件批量填充分散的 SG 表缓冲区为指定值（类似 memset，但由 DMA 完成）· DMA_INTERRUPT 【非传输类型】是 DMA 传输描述符的属性标记（而非 dma_transaction_type 成员），表示 “传输完成后触发硬件中断”例如，它在i.MX DMA控制器驱动程序中的设置如下：

dma_cap_set(DMA_SLAVE, sdma->dma_device.cap_mask);dma_cap_set(DMA_CYCLIC, sdma->dma_device.cap_mask);dma_cap_set(DMA_MEMCPY, sdma->dma_device.cap_mask);

· src_addr_widths：设备支持的源地址宽度的位掩码。这个宽度必须以字节为单位提供。例如，如果设备支持的宽度为4，那么位掩码应该设置为BIT(4)。· dst_addr_widths：设备支持的目的地址宽度的位掩码。· directions：设备支持的从属方向的位掩码。因为enum dma_transfer_direction不包括每种类型的位标志，所以DMA控制器应该设置BIT()，并且同样应该由控制器进行检查。

· enum dma_transfer_direction（如DMA_TO_DEVICE/DMA_FROM_DEVICE）本身是枚举值（比如 0、1、2），而非位标志，因此内核要求用BIT(<枚举值>)转成位掩码 —— 比如支持 “设备到内存” 和 “内存到设备”，则directions = BIT(DMA_FROM_DEVICE) | BIT(DMA_TO_DEVICE)，本质还是利用位掩码的上述优势，统一校验逻辑。它在i.MX SDMA控制器驱动程序中的设置如下：

#define SDMA_DMA_DIRECTIONS (BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_DEV))[...]sdma->dma_device.directions = SDMA_DMA_DIRECTIONS;

· device_alloc_chan_resources：一个通用的回调函数，用于分配资源并返回分配的描述符的数量。当在这个控制器上请求一个通道时，该函数将由DMA引擎核心调用。

· device_free_chan_resources：一个控制器回调函数，用于释放DMA通道的资源。该函数依赖于控制器的能力，如果在cap_mask中设置了能力位掩码，就必须提供相关的能力信息。

· device_prep_dma_memcpy：准备执行memcpy操作。如果在cap_mask中设置了DMA_MEMCPY，则必须设置这个字段。对于每个设置的标志，必须提供相应的回调函数，否则控制器注册将失败。这适用于所有的device_prep_*回调函数。

· device_prep_dma_xor：准备执行XOR操作。

· device_prep_dma_xor_val：准备执行XOR验证操作。

· device_prep_dma_memset：准备执行memset操作。

· device_prep_dma_memset_sg：准备对分散列表执行memset操作

· device_prep_dma_interrupt：准备执行链末中断操作。

· device_prep_slave_sg：构建 “从设备（SD 卡）↔ 内存” 的 SG 表传输描述符。

· device_prep_dma_cyclic：准备执行循环的DMA操作。这样的DMA操作在音频或UART驱动程序中经常使用。该函数需要一个大小为buf_len的缓冲区。在传输完period_len字节后，该函数将被调用。

· device_prep_interleaved_dma：构建 “交错传输” 描述符（多媒体多通道交织）。

· device_config：向通道推送新的配置。如果推送成功，返回0，否则返回错误码。

· device_pause：暂停通道上当前的任何传输。如果暂停有效，返回0，否则返回错误码。

· device_resume：恢复通道上先前暂停的任何传输。如果恢复有效，返回0，否则返回错误码。

· device_terminate_all：终止一个通道上的所有传输。如果成功，返回0，否则返回错误码。

· device_synchronize：数据传输终止后，将这一情况通知当前上下文。

· device_tx_status：对传输完成情况进行投票。可选的txstate参数可以用来获得一个结构体，该结构体包含辅助传输状态的信息；否则，该调用将只返回简单的状态码。

· device_issue_pending：一个强制性的回调函数，用于将待处理事务推送到硬件。它是dma_async_issue_ pending() API的后端函数。

虽然大多数驱动程序通过dma_chan->dma_dev->device_prep_dma直接调用这些回调函数，但你应该使用DMA引擎API dmaengine_prep_，这些API在调用适当的回调函数之前，还会进行一些合理性检查。例如，对于内存到内存复制，驱动程序应该使用device_prep_dma_memcpy()封装函数。

DMA通道数据结构

 DMA通道是客户端驱动程序向DMA控制器提交DMA事务（I/O数据传输）的方式。它的工作原理如下：具有DMA能力的驱动程序（客户端驱动程序）请求一个（或多个）通道，然后重新配置这个（或这些）通道，并要求控制器使用这个（或这些）通道来完成所提交的DMA传输。通道的定义如下：

struct dma_chan {struct dma_device *device;struct device *slave;dma_cookie_t cookie;dma_cookie_t completed_cookie;	[...]};

你可以把DMA通道看作I/O数据传输的高速公路。以上数据结构中每个字段的含义如下。· device：这是一个指向提供该通道的DMA设备（控制器）的指针。如果通道申请成功，则这个字段永远不能为NULL，因为一个通道总是属于一个控制器。· slave：这是一个指向使用该通道的设备的底层struct device数据结构的指针（该设备的驱动程序是一个客户端驱动程序）。· cookie：该通道最后返回给客户端的cookie值。· completed_cookie：该通道最后完成的cookie值。struct dma_chan数据结构的完整定义可以在include/linux/dmaengine.h中找到。在DMA引擎框架中，cookie只不过是一个DMA事务标识符，用于检查它所标识的事务的状态和进展情况。cookie = 你在快递站（DMA 通道）寄的 “最后一个快递的单号”（唯一、递增）；completed_cookie = 快递站看板上写的 “最后一个派送完成的快递单号”；通过对比这两个单号，就能知道 “最新寄的快递有没有送完”，也能知道整个通道的传输进度。

DMA事务描述符的数据结构

 事务描述符仅用于表征和描述DMA事务（或者说DMA传输），而不会执行其他操作。事务描述符在内核中使用struct dma_async_tx_descriptor数据结构来表示，该数据结构定义如下： 

struct dma_async_tx_descriptor {    dma_cookie_t cookie;    struct dma_chan *chan;    dma_async_tx_callback callback;    void *callback_param;    [...]};

以上数据结构中各个字段的含义如下。· cookie：当前事务的跟踪cookie，用于检查事务的进展情况。· chan：此操作的目标通道。· callback：一旦此操作完成，就应该被调用一个函数。· callback_param：作为回调函数的一个参数给出。该数据结构的完整定义可以在include/linux/dmaengine.h中找到。

处理DMA设备寻址能力

有些设备可能只支持低24位的寻址。这种限制缘于ISA总线，ISA总线是24位宽的，而DMA缓冲区只能存在于系统内存的16MB低地址中。尽管如此，我们仍然可以使用DMA掩码的概念来告知内核这种限制，目的是让内核知道设备的DMA寻址能力。这可以通过dma_set_mask_and_coherent()函数来实现，该函数的原型如下：

intdma_set_mask_and_coherent(struct device *dev, u64 mask);

 鉴于DMA API保证了相干DMA掩码可以设置为与流式DMA掩码相同或更小，上面的函数将为流DMA映射和一致性DMA映射设置相同的掩码。 

 然而，对于特殊需求，可以使用dma_set_mask()或dma_set_ coherent_mask()函数来设置相应的掩码。这两个函数的原型如下： 

intdma_set_mask(struct device *dev, u64 mask);intdma_set_coherent_mask(struct device *dev, u64 mask);

其中，dev是底层设备结构；mask是位掩码，用于描述设备支持哪些位的地址，可以使用DMA_BIT_MASK宏指定要使用的位掩码及其实际的位顺序。

dma_set_mask()和dma_set_coherent_mask()函数都返回0，表示设备可以在给定地址掩码的机器上正常进行DMA。任何其他的返回值都是错误，意味着给定的掩码太小，系统不支持。在这种失败的情况下，可以选择回退到非DMA模式来进行驱动程序中的数据传输；或者，如果DMA支持是强制性的，则简单地禁用设备中要求DMA支持的功能，甚至不对设备进行探测。

建议让你的驱动程序在设置DMA掩码失败时打印一条内核警告[dev_warn()或pr_warn()]消息。下面是一个例子：

#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)#define RECORD_ADDRESS_BITSDMA_BIT_MASK(24)struct my_sound_card *card;struct device *dev;[...]if (!dma_set_mask(dev, PLAYBACK_ADDRESS_BITS)) {card->playback_enabled = 1;} else {card->playback_enabled = 0;dev_warn(dev, "%s: Playback disabled due to DMA limitations\n", card->name);} if (!dma_set_mask(dev, RECORD_ADDRESS_BITS)) {card->record_enabled = 1;} else {card->record_enabled = 0;dev_warn(dev, "%s: Record disabled due to DMA limitations\n", card->name);}

 在上面的例子中，我们使用DMA_BIT_MASK宏来定义DMA掩码。然后在所需的DMA掩码不被支持的情况下，我们禁用了强制要求DMA支持的功能。在以上任何一种情况下，都会打印一条警告消息。 

下一节，将继续拆解DMA