3. Mailbox驱动框架：Linux内核Mailbox子系统架构

Mailbox驱动，说白了就是处理器核之间、或者处理器与协处理器之间的一种“通信管道”。你想想看，两个独立的CPU核要交换数据，总不能直接读写对方的寄存器吧？那不乱套了。Linux内核的Mailbox子系统，就是帮我们把这个通信过程标准化、框架化。

我刚开始接触Mailbox驱动时，总觉得这东西不就是个“邮箱”嘛，发信收信而已。后来在调试一个异构多核项目时，踩了不少坑，才真正理解这个框架的设计精髓。今天我们就来拆解一下它的核心。

3.1 整体架构：三层的“邮局”模型

Linux内核Mailbox子系统分为三层，我习惯把它们比作一个邮局：

• 底层（硬件层）：就是实际的Mailbox硬件控制器，比如TI的Mailbox IP、ARM的MHU等。这部分由驱动开发者实现。
• 中间层（核心层）：内核提供的通用框架，负责管理通道、调度消息、回调通知。这部分你不用改，直接用。
• 上层（客户端层）：使用Mailbox通信的驱动，比如RPMSG、 remoteproc等。它们通过标准API申请通道、发送消息。

这种分层的好处很明显——你写底层驱动时，不用关心上层怎么用；上层开发者也不用管硬件细节。我在一个项目中就遇到过，硬件团队换了Mailbox IP，我只需要重写底层驱动，上层的RPMSG驱动一行代码都没动。

3.2 核心数据结构详解

这三个结构体，是Mailbox驱动的“三驾马车”。我当年调试时，就是靠把它们的关系理清楚，才定位到一个通道泄漏的bug。下面我们一个一个看。

3.2.1 struct mbox_controller —— 硬件控制器的“身份证”

这个结构体描述了一个Mailbox硬件控制器。一个SoC里可能有多个Mailbox控制器，每个控制器对应一个mbox_controller实例。

struct mbox_controller {
    struct device *dev;                 // 关联的设备
    const char *name;                   // 控制器名称
    unsigned int num_chans;             // 通道数量
    struct mbox_chan *chans;            // 通道数组
    struct mbox_chan_ops *ops;          // 硬件操作函数集
    struct list_head node;              // 链表节点
    bool txdone_poll;                   // 是否轮询发送完成
    unsigned int txpoll_period;         // 轮询周期(ms)
};

这里我特别想强调txdone_poll这个字段。有些硬件不支持发送完成中断，就得靠轮询。我曾经在一个项目中，硬件设计漏掉了TX完成信号，只能把txdone_poll设为true，轮询周期设成10ms。结果上层RPMSG通信延迟飙升，后来改成1ms才勉强能用。所以，硬件设计时一定要留TX完成中断，不然性能很难看。

字段	说明	避坑点
num_chans	通道数量，必须与硬件一致	写少了通道不够用，写多了内存浪费
ops	硬件操作函数，包括send、startup、shutdown等	所有函数指针必须实现，否则内核会panic
txdone_poll	是否使用轮询检测发送完成	能不用就不用，轮询太费CPU

3.2.2 struct mbox_chan —— 通信的“管道”

每个通道代表一条独立的通信链路。一个控制器下有多个通道，通道之间相互隔离。

struct mbox_chan {
    struct mbox_controller *mbox;       // 所属控制器
    unsigned int idx;                   // 通道索引
    struct mbox_client *cl;             // 当前使用的客户端
    struct completion tx_complete;      // 发送完成同步
    void *con_priv;                     // 硬件私有数据
};

con_priv这个字段很关键。它指向硬件相关的私有数据，比如通道对应的寄存器基址、中断号等。我见过有人把整个控制器的寄存器基址存在这里，结果多个通道共用一个基址，中断处理时全乱了。正确的做法是：每个通道的con_priv只存该通道相关的信息。

3.2.3 struct mbox_client —— 通信的“用户”

客户端结构体由上层驱动定义，描述谁在使用这个通道。

struct mbox_client {
    struct device *dev;                 // 客户端设备
    bool tx_block;                      // 发送是否阻塞
    unsigned int tx_tout;               // 发送超时(ms)
    bool knows_txdone;                  // 是否知道发送完成
    void (*rx_callback)(struct mbox_client *cl, void *mssg);
    void (*tx_prepare)(struct mbox_client *cl, void *mssg);
    void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
};

rx_callback是收信回调，当硬件收到消息时，核心层会调用这个函数。我在调试一个音频DSP通信时，发现rx_callback里不能做耗时操作，否则会阻塞中断上下文。后来改成在回调里只做消息入队，真正处理放到工作队列里，问题就解决了。

3.3 三者关系：一次完整的通信流程

这三个结构体怎么配合工作？我画个流程图你就明白了。

1. 注册控制器：驱动probe时，分配mbox_controller，调用mbox_controller_register()注册到核心层。
2. 请求通道：客户端调用mbox_request_channel()，传入mbox_client，核心层从控制器中分配一个空闲的mbox_chan。
3. 发送消息：客户端调用mbox_send_message()，核心层调用mbox_chan->mbox->ops->send_data()，将数据写入硬件。
4. 接收消息：硬件中断触发，核心层调用mbox_chan->cl->rx_callback()，将数据传递给客户端。
5. 释放通道：客户端调用mbox_free_channel()，核心层将通道标记为空闲。

3.4 调试小技巧：如何快速验证框架是否正常工作

当你写完Mailbox驱动，怎么确认框架搭对了？我一般用这招：

# 查看系统中注册的Mailbox控制器
ls /sys/kernel/debug/mailbox/

# 查看每个控制器的通道状态
cat /sys/kernel/debug/mailbox/mbox_controller_name

# 手动触发一次发送测试（需要内核开启CONFIG_MAILBOX_TEST）
echo "test_message" > /sys/kernel/debug/mailbox/test_send

如果debugfs里能看到你的控制器和通道，说明注册成功了。如果发送测试能收到回调，那恭喜你，框架基本没问题。剩下的就是调性能了。

嗯，Mailbox子系统的核心框架就这些。三个结构体，三层架构，一条通信链路。理解了这个，后面我们讲故障定位和性能调优时，你就能快速找到问题出在哪一层。