说明：

　　Kernel版本：4.14

　　ARM64处理器

　　Linux PCI驱动框架分析（一）

　　1. 概述

　　从本文开始，将会针对PCIe专题来展开，涉及的内容包括：

　　PCI/PCIe总线硬件；

　　Linux PCI驱动核心框架；

　　Linux PCI Host控制器驱动；

　　不排除会包含PCIe外设驱动模块，一切随缘。

　　作为专题的第一篇，当然会先从硬件总线入手。进入主题前，先讲点背景知识。在PC时代，随着处理器的发展，经历了几代I/O总线的发展，解决的问题都是CPU主频提升与外部设备访问速度的问题：

　　第一代总线包含ISA、EISA、VESA和Micro Channel等；

　　第二代总线包含PCI、AGP、PCI-X等；

　　第三代总线包含PCIe、mPCIe、m.2等；

　　PCIe（PCI Express）是目前PC和嵌入式系统中最常用的高速总线，PCIe在PCI的基础上发展而来，在软件上PCIe与PCI是后向兼容的，PCI的系统软件可以用在PCIe系统中。

　　本文会分两部分展开，先介绍PCI总线，然后再介绍PCIe总线，方便在理解上的过渡，开始旅程吧。

　　2. PCI Local Bus

　　2.1 PCI总线组成

　　PCI总线（Peripheral Component Interconnect，外部设备互联），由Intel公司提出，其主要功能是连接外部设备；

　　PCI Local Bus，PCI局部总线，局部总线技术是PC体系结构发展的一次变革，是在ISA总线和CPU总线之间增加的一级总线或管理层，可将一些高速外设，如图形卡、硬盘控制器等从ISA总线上卸下，而通过局部总线直接挂接在CPU总线上，使之与高速CPU总线相匹配。PCI总线，指的就是PCI Local Bus。

　　先来看一下PCI Local Bus的系统架构图：

　　从图中看，与PCI总线相关的模块包括：

　　Host Bridge，比如PC中常见的North Bridge（北桥）。图中处理器、Cache、内存子系统通过Host Bridge连接到PCI上，Host Bridge管理PCI总线域，是联系处理器和PCI设备的桥梁，完成处理器与PCI设备间的数据交换。其中数据交换，包含处理器访问PCI设备的地址空间和PCI设备使用DMA机制访问主存储器，在PCI设备用DMA访问存储器时，会存在Cache一致性问题，这个也是Host Bridge设计时需要考虑的；此外，Host Bridge还可选的支持仲裁机制，热插拔等；

　　PCI Local Bus；PCI总线，由Host Bridge或者PCI-to-PCI Bridge管理，用来连接各类设备，比如声卡、网卡、IDE接口等。可以通过PCI-to-PCI Bridge来扩展PCI总线，并构成多级总线的总线树，比如图中的PCI Local Bus #0和PCI Local Bus #1两条PCI总线就构成一颗总线树，同属一个总线域；

　　PCI-To-PCI Bridge；PCI桥，用于扩展PCI总线，使采用PCI总线进行大规模系统互联成为可能，管理下游总线，并转发上下游总线之间的事务；

　　PCI Device；PCI总线中有三类设备：PCI从设备，PCI主设备，桥设备。PCI从设备：被动接收来自Host Bridge或者其他PCI设备的读写请求；PCI主设备：可以通过总线仲裁获得PCI总线的使用权，主动向其他PCI设备或主存储器发起读写请求；桥设备：管理下游的PCI总线，并转发上下游总线之间的总线事务，包括PCI桥、PCI-to-ISA桥、PCI-to-Cardbus桥等。

　　2.2 PCI总线信号定义

　　PCI总线是一条共享总线，可以挂接多个PCI设备，PCI设备通过一系列信号与PCI总线相连，包括：地址/数据信号、接口控制信号、仲裁信号、中断信号等。如下图：

　　左侧红色框里表示的是PCI总线必需的信号，而右侧蓝色框里表示的是可选的信号；

　　AD[31:00]：地址与数据信号复用，在传送时第一个时钟周期传送地址，下一个时钟周期传送数据；

　　C/BE[3:0]#：PCI总线命令与字节使能信号复用，在地址周期中表示的是PCI总线命令，在数据周期中用于字节选择，可以进行单字节、字、双字访问；

　　PAR：奇偶校验信号，确保AD[31:00]和C/BE[3:0]#传递的正确性；

　　Interface Control：接口控制信号，主要作用是保证数据的正常传递，并根据PCI主从设备的状态，暂停、终止或者正常完成总线事务：

　　FRAME#：表示PCI总线事务的开始与结束；

　　IRDY#：信号由PCI主设备驱动，信号有效时表示PCI主设备数据已经ready；

　　TRDY#：信号由目标设备驱动，信号有效时表示目标设备数据已经ready；

　　STOP#：目标设备请求主设备停止当前总线事务；

　　DEVSEL#：PCI总线的目标设备已经准备好；

　　IDSEL：PCI总线在配置读写总线事务时，使用该信号选择PCI目标设备；

　　Arbitration：仲裁信号，由REQ#和GNT#组成，与PCI总线的仲裁器直接相连，只有PCI主设备需要使用该组信号，每条PCI总线上都有一个总线仲裁器；

　　Error Reporting：错误信号，包括PERR#奇偶校验错误和SERR系统错误；

　　System：系统信号，包括时钟信号和复位信号；

　　看一下C/BE[3:0]都有哪些命令吧：

　　2.3 PCI事务模型

　　PCI使用三种模型用于数据的传输：

　　Programmed I/O：通过IO读写访问PCI设备空间；

　　DMA：PIO的方式比较低效，DMA的方式可以直接去访问主存储器而无需CPU干预，效率更高；

　　Peer-to-peer：两台PCI设备之间直接传送数据；

　　2.4 PCI总线地址空间映射

　　PCI体系架构支持三种地址空间：

　　memory空间：针对32bit寻址，支持4G的地址空间，针对64bit寻址，支持16EB的地址空间；

　　I/O空间PCI最大支持4G的IO空间，但受限于x86处理器的IO空间（16bits带宽），很多平台将PCI的IO地址空间限定在64KB；

　　配置空间x86 CPU可以直接访问memory空间和I/O空间，而配置空间则不能直接访问；每个PCI功能最多可以有256字节的配置空间；PCI总线在进行配置的时候，采用ID译码方式，使用设备的ID号，包括Bus Number，Device Number，Function Number和Register Number，每个系统支持256条总线，每条总线支持32个设备，每个设备支持8个功能，由于每个功能最多有256字节的配置空间，因此总的配置空间大小为：256B * 8 * 32 * 256 = 16M；

　　有必要再进一步介绍一下配置空间：x86 CPU无法直接访问配置空间，通过IO映射的数据端口和地址端口间接访问PCI的配置空间，其中地址端口映射到0CF8h - 0CFBh，数据端口映射到0CFCh - 0CFFh；

　　图为配置地址寄存器构成，PCI的配置过程分为两步：

　　CPU写CF8h端口，其中写的内容如图所示，BUS，Device，Function能标识出特定的设备功能，Doubleword来指定配置空间的具体某个寄存器；

　　CPU可以IO读写CFCh端口，用于读取步骤1中的指定寄存器内容，或者写入指定寄存器内容。这个过程有点类似于通过I2C去配置外接芯片；

　　那具体的配置空间寄存器都是什么样的呢？每个功能256Byte，前边64Byte是Header，剩余的192Byte支持可选功能。有种类型的PCI功能：Bridge和Device，两者的Header都不一样。

　　Bridge

　　Device

　　配置空间中有个寄存器字段需要说明一下：

　　Base Address Register，也就是BAR空间，当PCI设备的配置空间被初始化后，该设备在PCI总线上就会拥有一个独立的PCI总线地址空间，这个空间就是BAR空间，BAR空间可以存放IO地址空间，也可以存放存储器地址空间。

　　PCI总线取得了很大的成功，但随着CPU的主频不断提高，PCI总线的带宽也捉襟见肘。此外，它本身存在一些架构上的缺陷，面临一系列挑战，包括带宽、流量控制、数据传送质量等；

　　PCIe应运而生，能有效解决这些问题，所以PCIe才是我们的主角；

　　3. PCI Express

　　3.1 PCIe体系结构

　　先看一下PCIe架构的组成图：

　　Root Complex：CPU和PCIe总线之间的接口可能会包含几个模块（处理器接口、DRAM接口等），甚至可能还会包含芯片，这个集合就称为Root Complex，它作为PCIe架构的根，代表CPU与系统其它部分进行交互。广义来说，Root Complex可以认为是CPU和PCIe拓扑之间的接口，Root Complex会将CPU的request转换成PCIe的4种不同的请求（Configuration、Memory、I/O、Message）；

　　Switch：从图中可以看出，Swtich提供扇出能力，让更多的PCIe设备连接在PCIe端口上；

　　Bridge：桥接设备，用于去连接其他的总线，比如PCI总线或PCI-X总线，甚至另外的PCIe总线；

　　PCIe Endpoint：PCIe设备；

　　图中白色的小方块代表Downstream端口，灰色的小方块代表Upstream端口；

　　前文提到过，PCIe在软件上保持了后向兼容性，那么在PCIe的设计上，需要考虑在PCI总线上的软件视角，比如Root Complex的实现可能就如下图所示，从而看起来与PCI总线相差无异：

　　Root Complex通常会实现一个内部总线结构和多个桥，从而扇出到多个端口上；

　　Root Complex的内部实现不需要遵循标准，因此都是厂家specific的；

　　而Switch的实现可能如下图所示：

　　Switch就是一个扩展设备，所以看起来像是各种桥的连接路由；

　　3.2 PCIe数据传输

　　与PCI总线不同（PCI设备共享总线），PCIe总线使用端到端的连接方式，互为接收端和发送端，全双工，基于数据包的传输；

　　物理底层采用差分信号（PCI链路采用并行总线，而PCIe链路采用串行总线），一条Lane中有两组差分信号，共四根信号线，而PCIe Link可以由多条Lane组成，可以支持1、2、4、8、12、16、32条；

　　PCIe规范定义了分层的架构设计，包含三层：

　　Transaction层

　　负责TLP包（Transaction Layer Packet）的封装与解封装，此外还负责QoS，流控、排序等功能；

　　Data Link层

　　负责DLLP包（Data Link Layer Packet）的封装与解封装，此外还负责链接错误检测和校正，使用Ack/Nak协议来确保传输可靠；

　　Physical层

　　负责Ordered-Set包的封装与解封装，物理层处理TLPs、DLLPs、Ordered-Set三种类型的包传输；

　　数据包的封装与解封装，与网络包的创建与解析很类似，如下图：

　　封装的时候，在Payload数据前添加各种包头，解析时是一个逆向的过程；

　　来一个更详细的PCIe分层图：

　　3.3 PCIe设备的配置空间

　　为了兼容PCI软件，PCIe保留了256Byte的配置空间，如下图：

　　此外，在这个基础上将配置空间扩展到了4KB，还进行了功能的扩展，比如Capability、Power Management、MSI中断等：

　　扩展后的区域将使用MMIO的方式进行访问；

　　草草收场吧，对PCI和PCIe有一些轮廓上的认知了，可以开始Source Code的软件分析了，欲知详情、下回分解！

　　Linux PCI驱动框架分析（二）

　　1. 概述

　　本文将分析Linux PCI子系统的框架，主要围绕Linux PCI子系统的初始化以及枚举过程分析；

　　如果对具体的硬件缺乏了解，建议先阅读上篇文章《Linux PCI驱动框架分析（一）》；

　　话不多说，直接开始。

　　2. 数据结构

　　PCI体系结构的拓扑关系如图所示，而图中的不同数据结构就是用于来描述对应的模块；

　　Host Bridge连接CPU和PCI系统，由struct pci_host_bridge描述；

　　struct pci_dev描述PCI设备，以及PCI-to-PCI桥设备；

　　struct pci_bus用于描述PCI总线，struct pci_slot用于描述总线上的物理插槽；

　　来一张更详细的结构体组织图：

　　总体来看，数据结构对硬件模块进行了抽象，数据结构之间也能很便捷的构建一个类似PCI子系统物理拓扑的关系图；

　　顶层的结构为pci_host_bridge，这个结构一般由Host驱动负责来初始化创建；

　　pci_host_bridge指向root bus，也就是编号为0的总线，在该总线下，可以挂接各种外设或物理slot，也可以通过PCI桥去扩展总线；

　　3. 流程分析

　　3.1 设备驱动模型

　　Linux PCI驱动框架，基于Linux设备驱动模型，因此有必要先简要介绍一下，实际上Linux设备驱动模型也是一个大的topic，先挖个坑，有空再来填。来张图吧：

　　简单来说，Linux内核建立了一个统一的设备模型，分别采用总线、设备、驱动三者进行抽象，其中设备与驱动都挂在总线上，当有新的设备注册或者新的驱动注册时，总线会去进行匹配操作（match函数），当发现驱动与设备能进行匹配时，就会执行probe函数的操作；

　　从数据结构中可以看出，bus_type会维护两个链表，分别用于挂接向其注册的设备和驱动，而match函数就负责匹配检测；

　　各类驱动框架也都是基于图中的机制来实现，在这之上进行封装，比如I2C总线框架等；

　　设备驱动模型中，包含了很多kset/kobject等内容，建议去看看之前的文章《linux设备模型之kset/kobj/ktype分析》

　　好了，点到为止，感觉要跑题了，强行拉回来。

　　3.2 初始化

　　既然说到了设备驱动模型，那么首先我们要做的事情，就是先在内核里边创建一个PCI总线，用于挂接PCI设备和PCI驱动，我们的实现来到了pci_driver_init()函数：

　　内核在PCI框架初始化时会调用pci_driver_init()来创建一个PCI总线结构（全局变量pci_bus_type），这里描述的PCI总线结构，是指驱动匹配模型中的概念，PCI的设备和驱动都会挂在该PCI总线上；

　　从pci_bus_type的函数操作接口也能看出来，pci_bus_match用来检查设备与驱动是否匹配，一旦匹配了就会调用pci_device_probe函数，下边针对这两个函数稍加介绍；

　　3.2.1 pci_bus_match

　　设备或者驱动注册后，触发pci_bus_match函数的调用，实际会去比对vendor和device等信息，这个都是厂家固化的，在驱动中设置成PCI_ANY_ID就能支持所有设备；

　　一旦匹配成功后，就会去触发pci_device_probe的执行；

　　3.2.2 pci_device_probe

　　实际的过程也是比较简单，无非就是进行匹配，一旦匹配上了，直接调用驱动程序的probe函数，写过驱动的同学应该就比较清楚后边的流程了；

　　3.3 枚举

　　我们还是顺着设备驱动匹配的思路继续开展；

　　3.2节描述的是总线的创建，那么本节中的枚举，显然就是设备的创建了；

　　所谓设备的创建，就是在Linux内核中维护一些数据结构来对硬件设备进行描述，而硬件的描述又跟上文中的数据结构能对应上；

　　枚举的入口函数：pci_host_probe

　　设备的扫描从pci_scan_root_bus_bridge开始，首先需要先向系统注册一个host bridge，在注册的过程中需要创建一个root bus，也就是bus 0，在pci_register_host_bridge函数中，主要是一系列的初始化和注册工作，此外还为总线分配资源，包括地址空间等；

　　pci_scan_child_bus开始，从bus 0向下扫描并添加设备，这个过程由pci_scan_child_bus_extend来完成；

　　从pci_scan_child_bus_extend的流程可以看出，主要有两大块：

　　PCI设备扫描，从循环也能看出来，每条总线支持32个设备，每个设备支持8个功能，扫描完设备后将设备注册进系统，pci_scan_device的过程中会去读取PCI设备的配置空间，获取到BAR的相关信息，细节不表了；

　　PCI桥设备扫描，PCI桥是用于连接上一级PCI总线和下一级PCI总线的，当发现有下一级总线时，创建子结构，并再次调用pci_scan_child_bus_extend的函数来扫描下一级的总线，从这个过程看，就是一个递归过程。

　　从设备的扫描过程看，这是一个典型的DFS（Depth First Search）过程，熟悉数据结构与算法的同学应该清楚，这就类似典型的走迷宫的过程；

　　如果你对上述的流程还不清楚，再来一张图：

　　图中的数字代表的就是扫描的过程，当遍历到PCI桥设备的时候，会一直穷究到底，然后再返回来；

　　当枚举过程结束后，系统中就已经维护了PCI设备的各类信息了，在设备驱动匹配模型中，总线和设备都已经具备了，剩下的就是写个驱动了；

　　暂且写这么多，细节方面不再赘述了，把握大体的框架即可，无法扼住PCI的咽喉，那就扼住它的骨架吧。

　　Linux PCI驱动框架分析（三）

　　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：旧式的中断控制器；

　　2.2 probe流程

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

　　当驱动与设备通过compatible字段匹配上后，会调用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驱动实现；

　　2.3 中断处理

　　PCIe控制器，通过PCIe总线连接各种设备，因此它本身充当一个中断控制器，级联到上一层的中断控制器（比如GIC），如下图：

　　PCIe总线支持两种中断的处理方式：

　　Legacy Interrupt：总线提供INTA#, INTB#, INTC#, INTD#四根中断信号，PCI设备借助这四根信号使用电平触发方式提交中断请求；

　　MSI(Message Signaled Interrupt) Interrupt：基于消息机制的中断，也就是往一个指定地址写入特定消息，从而触发一个中断；

　　针对两种处理方式，NWL PCIe驱动中，实现了两个irq_chip，也就是两种方式的中断控制器：

　　irq_domain对应一个中断控制器（irq_chip），irq_domain负责将硬件中断号映射到虚拟中断号上；

　　来一张旧图吧，具体文章可以去参考中断子系统相关文章；

　　在该函数中主要完成的工作就是设置级联的中断处理函数，级联的中断处理函数中最终会去调用具体的设备的中断处理函数；

　　所以，稍微汇总一下，作为两种不同的中断处理方式，套路都是一样的，都是创建irq_chip中断控制器，为该中断控制器添加irq_domain，具体设备的中断响应流程如下：

　　设备连接在PCI总线上，触发中断时，通过PCIe控制器充当的中断控制器路由到上一级控制器，最终路由到CPU；

　　CPU在处理PCIe控制器的中断时，调用它的中断处理函数，也就是上文中提到过的nwl_pcie_leg_handler，nwl_pcie_msi_handler_high，和nwl_pcie_leg_handler_low；

　　在级联的中断处理函数中，调用chained_irq_enter进入中断级联处理；

　　调用irq_find_mapping找到具体的PCIe设备的中断号；

　　调用generic_handle_irq触发具体的PCIe设备的中断处理函数执行；

　　调用chained_irq_exit退出中断级联的处理；

　　2.4 总结

　　PCIe控制器驱动，各家的IP实现不一样，驱动的差异可能会很大，单独分析一个驱动毕竟只是个例，应该去掌握背后的通用框架；

　　各类驱动，大体都是硬件初始化配置，资源申请注册，核心是处理与硬件的交互（一般就是中断的处理），如果需要用户来交互的，则还需要注册设备文件，实现一堆file_operation操作函数集；

　　好吧，我个人不太喜欢分析某个驱动，草草收场了；