Linux PCI驱动框架分析（三）

type

Post

status

Published

date

Jul 28, 2025

slug

2025/07/28/Analysis-of-Linux-PCI-driver-framework-(3)

summary

背景

Read the fucking source code! --By 鲁迅

A picture is worth a thousand words. --By 高尔基

说明：

Kernel版本：4.14

ARM64处理器

使用工具：Source Insight 3.5， Visio

1. 概述

先回顾一下PCIe的架构图：

本文将讲PCIe Host的驱动，对应为Root Complex部分，相当于PCI的Host Bridge部分；

本文会选择Xilinx的nwl-pcie来进行分析；

驱动的编写整体偏简单，往现有的框架上套就可以了，因此不会花太多笔墨，点到为止；

2. 流程分析

但凡涉及到驱动的分析，都离不开驱动模型的介绍，驱动模型的实现让具体的驱动开发变得更容易；

所以，还是回顾一下上篇文章提到的驱动模型：Linux内核建立了一个统一的设备模型，分别采用总线、设备、驱动三者进行抽象，其中设备与驱动都挂在总线上，当有新的设备注册或者新的驱动注册时，总线会去进行匹配操作（match函数），当发现驱动与设备能进行匹配时，就会执行 probe 函数的操作；

《Linux PCI驱动框架分析（二）》中提到过PCI设备、PCI总线和PCI驱动的创建，PCI设备和PCI驱动挂接在PCI总线上，这个理解很直观。针对PCIe的控制器来说，同样遵循设备、总线、驱动的匹配模型，不过这里的总线是由虚拟总线platform总线来替代，相应的设备和驱动分别为platform_device和platform_driver；

那么问题来了，platform_device是在什么时候创建的呢？那就不得不提到Device Tree设备树了。

2.1 Device Tree

设备树用于描述硬件的信息，包含节点各类属性，在 dts 文件中定义，最终会被编译成 dtb 文件加载到内存中；

内核会在启动过程中去解析 dtb 文件，解析成device_node描述的Device Tree；

根据device_node节点，创建platform_device结构，并最终注册进系统，这个也就是 PCIe Host 设备的创建过程；

我们看看 PCIe Host 的设备树内容：

关键字段描述如下：

compatible：用于匹配 PCIe Host 驱动；

msi-controller：表示是一个MSI（Message Signaled Interrupt）控制器节点，这里需要注意的是，有的 SoC 中断控制器使用的是 GICv2 版本，而 GICv2 并不支持 MSI，所以会导致该功能的缺失；

device-type：必须是"pci"；

interrupts：包含 NWL PCIe 控制器的中断号；

interrupts-name：msi1, msi0用于MSI中断，intx用于旧式中断，与interrupts中的中断号对应；

reg：包含用于访问 PCIe 控制器操作的寄存器物理地址和大小；

reg-name：分别表示Bridge registers，PCIe Controller registers， Configuration space region，与reg中的值对应；

ranges：PCIe 地址空间转换到 CPU 的地址空间中的范围；

bus-range：PCIe 总线的起始范围；

interrupt-map-mask和interrupt-map：标准PCI属性，用于定义PCI接口到中断号的映射；

legacy-interrupt-controller：旧式的中断控制器；


pcie: pcie@fd0e0000 {
 compatible = "xlnx,nwl-pcie-2.11";
 status = "disabled";
 #address-cells = <3>;
 #size-cells = <2>;
 #interrupt-cells = <1>;
 msi-controller;
 device_type = "pci";

 interrupt-parent = <&gic>;
 interrupts = <0 118 4>,
              <0 117 4>,
              <0 116 4>,
              <0 115 4>, /* MSI_1 [63...32] */
              <0 114 4>; /* MSI_0 [31...0] */
 interrupt-names = "misc", "dummy", "intx", "msi1", "msi0";
 msi-parent = <&pcie>;

 reg = <0x0 0xfd0e0000 0x0 0x1000>,
       <0x0 0xfd480000 0x0 0x1000>,
       <0x80 0x00000000 0x0 0x1000000>;
 reg-names = "breg", "pcireg", "cfg";
 ranges = <0x02000000 0x00000000 0xe0000000 0x00000000 0xe0000000 0x00000000 0x10000000 /* non-prefetchable memory */
    0x43000000 0x00000006 0x00000000 0x00000006 0x00000000 0x00000002 0x00000000>;/* prefetchable memory */
 bus-range = <0x00 0xff>;

 interrupt-map-mask = <0x0 0x0 0x0 0x7>;
 interrupt-map =   <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
                   <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
                   <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
                   <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;

 pcie_intc: legacy-interrupt-controller {
  interrupt-controller;
  #address-cells = <0>;
  #interrupt-cells = <1>;
 };
};

2.2 probe流程

系统会根据 dtb 文件创建对应的 platform_device 并进行注册；

当驱动与设备通过compatible字段匹配上后，会调用 probe 函数，也就是nwl_pcie_probe；

看一下nwl_pcie_probe函数：

通常 probe 函数都是进行一些初始化操作和注册操作：

初始化包括：数据结构的初始化以及设备的初始化等，设备的初始化则需要获取硬件的信息（比如寄存器基地址，长度，中断号等），这些信息都从 DTS 而来；

注册操作主要是包含中断处理函数的注册，以及通常的设备文件注册等;

针对PCI控制器的驱动，核心的流程是需要分配并初始化一个pci_host_bridge结构，最终通过这个bridge去枚举PCI总线上的所有设备；

devm_pci_alloc_host_bridge：分配并初始化一个基础的pci_hsot_bridge结构；

nwl_pcie_parse_dt：获取DTS中的寄存器信息及中断信息，并通过irq_set_chained_handler_and_data设置intx中断号对应的中断处理函数，该处理函数用于中断的级联；

nwl_pcie_bridge_init：硬件的Controller一堆设置，这部分需要去查阅Spec，了解硬件工作的细节。此外，通过devm_request_irq注册misc中断号对应的中断处理函数，该处理函数用于控制器自身状态的处理；

pci_parse_request_of_pci_ranges：用于解析PCI总线的总线范围和总线上的地址范围，也就是CPU能看到的地址区域；

nwl_pcie_init_irq_domain和mwl_pcie_enable_msi与中断级联相关，下个小节介绍；

pci_scan_root_bus_bridge：对总线上的设备进行扫描枚举，这个流程在Linux PCI驱动框架分析（二）中分析过。brdige结构体中的pci_ops字段，用于指向PCI的读写操作函数集，当具体扫描到设备要读写配置空间时，调用的就是这个函数，由具体的Controller驱动实现；