【原創】Linux PCI驅動框架分析（二）

背 景

• Read the fucking source code! --By 魯迅
• A picture is worth a thousand words. --By 高爾基

說明：

1. Kernel版本：4.14
2. ARM64處理器
3. 使用工具：Source Insight 3.5， Visio

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的流程可以看出，主要有兩大塊：
  1. PCI設備掃描，從循環也能看出來，每條總線支持32個設備，每個設備支持8個功能，掃描完設備後將設備註冊進系統，pci_scan_device的過程中會去讀取PCI設備的配置空間，獲取到BAR的相關信息，細節不表了；
  2. PCI橋設備掃描，PCI橋是用於連接上一級PCI總線和下一級PCI總線的，當發現有下一級總線時，創建子結構，並再次調用pci_scan_child_bus_extend的函數來掃描下一級的總線，從這個過程看，就是一個遞歸過程。
• 從設備的掃描過程看，這是一個典型的DFS（Depth First Search）過程，熟悉數據結構與算法的同學應該清楚，這就類似典型的走迷宮的過程；

如果你對上述的流程還不清楚，再來一張圖：

• 圖中的數字代表的就是掃描的過程，當遍歷到PCI橋設備的時候，會一直窮究到底，然後再返回來；
• 當枚舉過程結束後，系統中就已經維護了PCI設備的各類信息了，在設備驅動匹配模型中，總線和設備都已經具備了，剩下的就是寫個驅動了；

暫且寫這麼多，細節方面不再贅述了，把握大體的框架即可，無法扼住PCI的咽喉，那就扼住它的骨架吧。

歡迎關注個人公衆號，不定期分享Linux內核相關技術文章：