![Linux 用户空间 PCI 驱动程序选项? (uio_pci_generic)](https://linux22.com/image/70221/Linux%20%E7%94%A8%E6%88%B7%E7%A9%BA%E9%97%B4%20PCI%20%E9%A9%B1%E5%8A%A8%E7%A8%8B%E5%BA%8F%E9%80%89%E9%A1%B9%EF%BC%9F%20%EF%BC%88uio_pci_generic%EF%BC%89.png)
我的 PCI 总线上有一个 Xilinx FPGA PCIe 端点。 Linux 很好地识别了设备,lspci 中的一切看起来都很完美。
我的问题是关于用户空间的 PCI 访问选项以及什么是好/坏。
选项 1:通过 /sys/.../resource0 直接访问
(到目前为止我只成功完成了一项工作)
我可以打开并 mmap 说 /sys/bus/pci/devices/XXXX:XX:XX.X/resource0 然后 mmap 并读/写。只需要先修复权限即可。我的问题是,这是好还是坏方法?感觉这可能不是访问 PCI 地址空间的首选方法?
选项 2:使用 uio_pci_generic
我已经成功配置我的 FPGA,以便该驱动程序能够实际连接,但它需要中断这一事实确实很烦人。似乎这无法访问任何接受中断和配置内存空间?这对我来说似乎不太有用?我错过了什么吗?
选项 3:编写我自己的 uio 驱动程序
这也许是一个合理的选择?我不太确定这有多困难。这样做的一个可能的优点是我可以访问 DMA,从而大大加快速度。
选项 4:编写完全自定义的 Linux PCI 驱动程序
如果可能的话我想避免这个选项
我的问题是最好的方法是什么,以及选项 1 的具体缺点是什么。或者我应该考虑其他方法吗?
(我正在运行 debian,内核已打过 3.14.15 rt 补丁)
答案1
选项1(通过/sys/.../resource0直接访问)
适合测试,功能上没有任何问题,尽管不能做任何高级事情并且没有驱动程序层抽象。我发现这种方法很讨厌用户程序与 sysfs 交互的方式,但这可能是我个人的观点。
选项2(使用 uio_pci_generic)
我不知道 uio_pci_generic 是做什么的,但除了允许用户程序访问 pci 遗留中断之外,它似乎没有添加什么功能。这很糟糕,因为 MSI 无论如何都是首选。
选项3(自定义 uio 驱动程序)
我没有尝试过这个,但我怀疑与选项 4 相比有点浪费时间
选项4(自定义内核驱动程序)
这确实是最好的解决方案,也是正确做事的唯一方法。您需要一个驱动程序能够正确处理 DMA 和 MSI 等内容,并能够通过字符设备提供任意数量的抽象。然而,有大量关于如何在线编写 PCI 卡驱动程序的文档,并且内核为管理事物提供了大量支持。