3、DMA与数据流：DMA工作原理、环形缓冲区设计、零拷贝技术

各位好，咱们今天聊聊蓝牙驱动里最核心的数据搬运问题。说实话，蓝牙这玩意儿，数据量虽然比不上Wi-Fi，但它的实时性要求很苛刻。音频流一断，用户立马就能感觉到。我早期做的一个项目，就是被数据拷贝给坑惨了——CPU占用率飙到80%，手机直接发烫。后来才意识到，DMA和缓冲区设计才是真正的瓶颈。

3.1 DMA工作原理：让CPU歇口气

DMA，全称Direct Memory Access，直接存储器访问。说白了，就是让硬件自己搬数据，CPU在旁边喝茶就行。

为什么需要DMA？你想想看，蓝牙HCI层和Controller之间，数据是一包一包传的。如果没有DMA，CPU得一条指令一条指令地把数据从内存搬到UART或USB控制器。一次两次还行，音频流每秒几十上百次，CPU就彻底被拖垮了。

DMA的工作流程其实很简单：

1. 配置阶段：CPU设置DMA控制器的源地址、目标地址、传输长度、触发源。
2. 启动阶段：CPU写一个寄存器，告诉DMA“开始干活”。
3. 传输阶段：DMA自己从源地址读数据，写到目标地址。每传完一个单元，计数器减一。
4. 完成阶段：计数器归零，DMA触发中断，告诉CPU“活干完了”。

我记得在调试一个蓝牙音频dongle时，发现音频总是断断续续。查了半天，原来是DMA的触发源配错了。我配成了软件触发，结果每次都要CPU手动启动DMA，那还不如不用DMA呢。后来改成硬件触发——UART的RX引脚一有数据，DMA自动启动，问题就解决了。

3.2 环形缓冲区设计：解决数据堆积的利器

有了DMA，数据搬运快了。但数据往哪儿放？这就引出了环形缓冲区。

环形缓冲区，也叫循环队列。它是一块固定大小的内存，用两个指针来管理：读指针和写指针。写指针追着读指针跑，读指针追着写指针跑。就像一个环形跑道，永远不越界。

为什么用环形缓冲区？我举个例子。蓝牙音频数据是连续不断的，如果用链表，每次都要malloc/free，碎片化严重，实时性也没保障。用环形缓冲区，一次性分配好内存，后续操作全是指针移动，零开销。

来看一个典型的环形缓冲区实现：

#define RING_BUF_SIZE 4096

struct ring_buffer {
    uint8_t buffer[RING_BUF_SIZE];
    volatile uint32_t head;  // 写指针
    volatile uint32_t tail;  // 读指针
};

// 写入数据
int ring_buf_write(struct ring_buffer *rb, uint8_t *data, uint32_t len) {
    uint32_t space;
    // 计算剩余空间
    space = (rb->tail - rb->head - 1) & (RING_BUF_SIZE - 1);
    if (space < len) {
        return -1; // 空间不足
    }
    for (uint32_t i = 0; i < len; i++) {
        rb->buffer[rb->head] = data[i];
        rb->head = (rb->head + 1) & (RING_BUF_SIZE - 1);
    }
    return 0;
}

// 读取数据
int ring_buf_read(struct ring_buffer *rb, uint8_t *data, uint32_t len) {
    uint32_t available;
    available = (rb->head - rb->tail) & (RING_BUF_SIZE - 1);
    if (available < len) {
        return -1; // 数据不足
    }
    for (uint32_t i = 0; i < len; i++) {
        data[i] = rb->buffer[rb->tail];
        rb->tail = (rb->tail + 1) & (RING_BUF_SIZE - 1);
    }
    return 0;
}

注意看，这里用了& (RING_BUF_SIZE - 1)来取模。为什么？因为RING_BUF_SIZE是2的幂，位运算比取模快得多。嗯，这个细节我踩过坑——一开始用的%取模，性能测试时发现环形缓冲区成了瓶颈。改成位运算后，吞吐量直接翻倍。

3.3 零拷贝技术：省掉最后一趟搬运

零拷贝，这个名字听起来很玄乎。其实说白了，就是让数据从源头到目的地，中间不经过任何多余的拷贝。

传统的蓝牙数据流是什么样的？

1. Controller通过DMA把数据放到内核缓冲区。
2. 内核把数据拷贝到用户空间的应用缓冲区。
3. 应用处理完，再拷贝到协议栈缓冲区。
4. 协议栈再拷贝到网络接口。

你数数，一次数据流，至少拷贝了3次。对于音频这种实时流，每次拷贝都是延迟和功耗的代价。

零拷贝的思路就是：让DMA直接把数据放到最终的位置，或者让应用直接操作DMA缓冲区。

在蓝牙驱动里，我常用的零拷贝方案有两种：

方案	原理	适用场景
DMA直接到应用缓冲区	应用提前注册一块物理连续的内存，DMA直接写入	音频播放、语音通话
内存映射（mmap）	将内核DMA缓冲区映射到用户空间，应用直接读写	数据采集、日志记录

我个人比较推荐第一种方案。为什么？因为mmap虽然省了拷贝，但涉及页表切换，实时性反而不好控制。而DMA直接写入应用缓冲区，只要保证内存物理连续，性能是最优的。

来看一个实际例子。在Linux蓝牙驱动中，HCI的UART传输可以用DMA+零拷贝：

// 分配DMA安全的缓冲区
struct sk_buff *skb = alloc_skb(len, GFP_DMA);
// 让DMA直接写入skb的数据区
dma_addr_t dma_addr = dma_map_single(dev, skb->data, len, DMA_FROM_DEVICE);
// 配置DMA传输
dma_engine_slave_config(chan, &config);
dmaengine_prep_slave_sg(chan, &dma_addr, 1, DMA_DEV_TO_MEM, flags);
// 启动DMA
dmaengine_submit(desc);
dma_async_issue_pending(chan);
// 传输完成后，skb直接交给协议栈，零拷贝

这段代码的关键在于：DMA直接把数据写到了skb的数据区。传输完成后，skb不需要任何拷贝，直接送给上层协议栈。这就是真正的零拷贝。

3.4 三者如何配合？

DMA、环形缓冲区、零拷贝，这三者不是孤立的。在实际的蓝牙驱动里，它们是一个完整的流水线：

• DMA负责从硬件搬运数据，不占用CPU。
• 环形缓冲区负责暂存数据，解决生产和消费的速度不匹配问题。
• 零拷贝负责减少不必要的内存拷贝，降低延迟和功耗。

我做过一个蓝牙音频项目，就是这三者的经典配合：

1. I2S接口通过DMA把音频数据写入环形缓冲区。
2. 环形缓冲区满了，触发中断。
3. 中断处理程序直接把这个缓冲区的指针传给音频编解码器。
4. 编解码器处理完，再通过DMA把数据送到扬声器。

整个过程，CPU只做了指针传递和少量控制，数据本身一次拷贝都没有。最终效果：CPU占用率从35%降到了5%，音频延迟从15ms降到了3ms。

好了，这一章就聊到这儿。下一章咱们会深入蓝牙协议栈的内存管理，看看那些看不见的“内存黑洞”到底藏在哪儿。