x86外设驱动如何移植到龙芯LoongArch？PCIe与DMA适配实战

说实话，接这个任务之前我也觉得，驱动移植也就是“把代码换个平台编一遍、有问题再改一改”的事。真正入了“龙芯k——走马观碑组VLLX驱动移植”这个项目才发现，最花时间的不是改代码，而是把平台上那些“隐含假设”一条条捞出来。VLLX原本是跑在x86侧的专用处理卡，整个驱动栈从PCI枚举到中断处理再到DMA路径，全是按x86的习惯写的。我们要做的不是简单交叉编译，而是先判断哪些代码是PCIe设备自身的逻辑、哪些是架构相关的地基。

这篇文章不讨论项目里不能展开的部分，只聊聊VLLX驱动移植时踩过的那些架构深水区，以及我自己实测后觉得能复用的排查套路。如果你也是第一次把某个x86外设驱动搬到龙芯这类非x86平台，希望这些文字能帮你少走一段弯路。内容从背景拆解、代码改造点讲起，中间穿插可落地的操作流程和现场问题记录，基本按我实际推进的先后顺序来。

1. 项目背景与整体思路

1.1 VLLX是什么任务

VLLX在我们项目里是一个内部代号，对应一块安装在PCIe插槽上的专用数据处理卡。它的上游厂商只提供x86 Linux驱动，而我们跑的平台是龙芯，属于LoongArch指令集体系。用户的诉求很明确：在这块板子上把VLLX识别出来、驱动正常加载、中断按时触发，数据面吞吐虽然暂时没做极限调优，但基本读写链路必须稳定。

从驱动结构看，VLLX的软件栈并不复杂：内核模块负责PCI设备枚举、BAR空间映射、中断申请、DMA描述符管理，用户态工具再通过字符设备接口下发任务。问题在于这个驱动写得太“x86本地化”了，里面藏着不少只在Intel/AMD环境里碰巧成立的写法。移植前我先把代码分成两层来看：

• 设备逻辑层：硬件寄存器布局、固件交互协议、数据收发流程。这些和CPU架构无关，原则上应该原样保留。
• 平台适配层：IO空间访问方式、中断向量分配、DMA一致性映射、内存屏障。这一层才是移植真正要动刀的地方。

这种分发很有必要，因为很多老驱动把平台相关代码和设备流程揉在一个函数里。看到满屏#ifdef CONFIG_X86的时候，最忌讳的就是跟着宏去改分支，而是先识别出哪些功能块是“为特定CPU服务的”，然后重新组织代码，让设备逻辑调用一套抽象的访问接口。

1.2 移植前应该先做架构差异评估

动手之前，我花了半天把VLLX驱动在x86环境里完整编了一遍，同时把龙芯平台的内核配置打开对照。这个步骤不能省，它直接决定了后续所有改造的工作量。我列过一张表，把常见的差异点分成必改、可能要改、大概率不用改三类：

一眼看去好像没多少东西，但这些差异叠加在一起，就会出现“编译通过、加载成功、一跑就挂”的诡异现象。所以我的原则是：每个和平台相关的调用点单独过一遍，不要用“原来在x86上没出过事”作为理由放过。

1.3 推进路线怎么设计

整个移植我拆成了五个阶段，每个阶段有明确的结束标志：

1. 环境准备与编译适配。拿到LoongArch工具链和对应内核源码，先把VLLX驱动编成内核模块，先不管运行效果，至少要能insmod。
2. 枚举与资源确认。在龙芯平台上确认PCIe设备能被系统识别，BAR和MSI-X能力表读出来，和x86侧对比。
3. 基础IO读写验证。通过驱动映射BAR，读取设备固件版本这类只读寄存器，验证IO通路。
4. 中断与数据面打通。先跑通INTx，再切到MSI/MSI-X；准备一块DMA缓冲区做回环测试。
5. 稳定性与异常排查。长时间跑压力，观察有误报错或设备失联。

每个阶段之间留了足够缓冲，因为平台异常往往不是单点原因。比如设备枚举不出来，可能是主板PCIe链路问题，也可能是内核配置缺了PCIEASPM相关内容；不能一上来就怀疑是驱动代码。

2. 驱动代码中绕不开的架构差异

2.1 BAR映射和寄存器访问，没那么简单

VLLX驱动在x86侧是靠pci_iomap把BAR映射成内核虚拟地址，然后用readl/writel操作寄存器。表面上这些API在龙芯内核里都有，但有几个地方必须重看。

首先是BAR类型的判断。x86主机上BIOS往往会为设备自动分配IO和MEM资源，很多老驱动图省事直接ioremap(pci_resource_start(pdev, 0), size)。这段代码如果遇到类型为IORESOURCE_IO的BAR0，在x86上通常也“碰巧能用”，因为x86 IO空间本质是独立地址空间。但换到龙芯平台，IO空间策略不同，直接把IO资源当内存来映射就会出问题。更稳妥的写法是先看标志再进分支：

c复制if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
    regs = pci_ioremap_bar(pdev, bar);
} else {
    /* IO BAR，考虑用request_region + inl/outl，或干脆让硬件使用MEM BAR */
    dev_err(&pdev->dev, "io bar is not supported now\n");
}

其次是pci_request_region的顺序。有人喜欢在`pci_enable_devic