說明：
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控制器操作的寄存器物理地址和大?。?/p>
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操作函數集；
好吧，我個人不太喜歡分析某個驅動，草草收場了；