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

LoyenWang發表於2020-12-29
Linux框架

背 景

  • 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核心相關技術文章：

相關文章