背 景

Read the fucking source code! --By 魯迅

A picture is worth a thousand words. --By 高爾基

說明：linux

Kernel版本：4.14

ARM64處理器

使用工具：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的流程能夠看出，主要有兩大塊：

PCI設備掃描，從循環也能看出來，每條總線支持32個設備，每一個設備支持8個功能，掃描完設備后將設備注冊進系統，pci_scan_device的過程當中會去讀取PCI設備的配置空間，獲取到BAR的相關信息，細節不表了；

PCI橋設備掃描，PCI橋是用于鏈接上一級PCI總線和下一級PCI總線的，當發現有下一級總線時，建立子結構，并再次調用pci_scan_child_bus_extend的函數來掃描下一級的總線，從這個過程看，就是一個遞歸過程。

從設備的掃描過程看，這是一個典型的DFS(Depth First Search)過程，熟悉數據結構與算法的同窗應該清楚，這就相似典型的走迷宮的過程；

若是你對上述的流程還不清楚，再來一張圖：3d

圖中的數字表明的就是掃描的過程，當遍歷到PCI橋設備的時候，會一直窮究到底，而后再返回來；

當枚舉過程結束后，系統中就已經維護了PCI設備的各種信息了，在設備驅動匹配模型中，總線和設備都已經具有了，剩下的就是寫個驅動了；

暫且寫這么多，細節方面再也不贅述了，把握大致的框架便可，沒法扼住PCI的咽喉，那就扼住它的骨架吧。code

歡迎關注我的公眾號，不按期分享Linux內核相關技術文章：

blog

總結

以上是生活随笔為你收集整理的linux 统一设备模型 pci,【原创】Linux PCI驱动框架分析（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。