zhoubin333

Linux PCIe驱动框架分析

0
阅读(2416)

 说明:

  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的系统架构图:

  微信截图_20221129145511.png

  从图中看,与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总线相连,包括:地址/数据信号、接口控制信号、仲裁信号、中断信号等。如下图:

  微信截图_20221129150026.png

  左侧红色框里表示的是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]都有哪些命令吧:

  微信截图_20221129151723.png

  2.3 PCI事务模型

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

  微信截图_20221129151751.png

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

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

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

  2.4 PCI总线地址空间映射

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

  微信截图_20221129151937.png

  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;

  微信截图_20221129151952.png

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

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

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

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

  Bridge

  微信截图_20221129153234.png

  Device

  微信截图_20221129153250.png

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

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

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

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

  3. PCI Express

  3.1 PCIe体系结构

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

  微信截图_20221129153333.png

  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总线相差无异:

  微信截图_20221129153351.png

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

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

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

  微信截图_20221129153405.png

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

  3.2 PCIe数据传输

  微信截图_20221129153434.png

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

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

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

  微信截图_20221129153802.png

  Transaction层

  负责TLP包(Transaction Layer Packet)的封装与解封装,此外还负责QoS,流控、排序等功能;

  Data Link层

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

  Physical层

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

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

  微信截图_20221129153837.png

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

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

  微信截图_20221129154056.png

  3.3 PCIe设备的配置空间

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

  微信截图_20221129154153.png

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

  微信截图_20221129154211.png

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

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

  Linux PCI驱动框架分析(二)

  1. 概述

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

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

  话不多说,直接开始。

  2. 数据结构

  微信截图_20221129154240.png

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

  Host Bridge连接CPU和PCI系统,由struct pci_host_bridge描述;

  struct pci_dev描述PCI设备,以及PCI-to-PCI桥设备;

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

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

  微信截图_20221129154617.png

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

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

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

  3. 流程分析

  3.1 设备驱动模型

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

  微信截图_20221129154827.png

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

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

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

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

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

  3.2 初始化

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

  微信截图_20221129154919.png

  内核在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

  微信截图_20221129160803.png

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

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

  3.2.2 pci_device_probe

  微信截图_20221129160818.png

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

  3.3 枚举

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

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

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

  枚举的入口函数:pci_host_probe

  微信截图_20221129160901.png

  设备的扫描从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)过程,熟悉数据结构与算法的同学应该清楚,这就类似典型的走迷宫的过程;

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

  微信截图_20221129160920.png

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

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

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

  Linux PCI驱动框架分析(三)

  1. 概述

  先回顾一下PCIe的架构图:

  微信截图_20221129161207.png

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

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

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

  2. 流程分析

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

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

  微信截图_20221129161222.png

  《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的设备树内容:

 微信截图_20221129161252.png

  关键字段描述如下:

  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;

 微信截图_20221129161411.png

  通常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),如下图:

  微信截图_20221129161436.png

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

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

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

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

  微信截图_20221129161453.png

  irq_domain对应一个中断控制器(irq_chip),irq_domain负责将硬件中断号映射到虚拟中断号上;

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

  微信截图_20221129161825.png

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

  所以,稍微汇总一下,作为两种不同的中断处理方式,套路都是一样的,都是创建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操作函数集;

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