Linux驅動之platform總線詳解
1、platform 總線簡介
1.1、Linux 驅動的分離和分層思想
1.1.1、Linux 驅動的分離
? ? ? ? 先講 Linux 驅動的分離，Linux 操作系統(tǒng)支持在各類 CPU 上運行，因為每一種 CPU 對設備的驅動不一樣，這樣就造成了 Linux 內核中積累了大量代碼，并且這些代碼關于同一設備的描述大致相同，這就使得內核代碼很冗余。以 CPU 通過 I2C 控制 MPU6050 為例：
? ? ? ? 從圖可以看出每一種平臺下都有一套主機驅動和一套設備驅動，因為每個平臺的 I2C 控制器不同，所以這個主機驅動得每個平臺配一個自己的，但大家所用的 MPU6050 是一樣的，所以完全可以就共用一套設備驅動代碼。完善后框架如下：
????????當然，這只是對于 I2C 下的 MPU6050 這個設備，實際情況下，I2C 下肯定會掛載很多設備，根據(jù)這個思路，我們可以得到框架為：
? ? ? ? ?而在實際開發(fā)中，I2C 主機驅動半導體廠家會編寫好，設備驅動也由設備廠家編寫好，我們只需要提供設備信息即可，如設備接到那個 I2C 接口上，I2C 速度為多少。這樣就相當于把設備信息從設備驅動中剝離出來，而設備驅動也會用標準方法去獲取設備信息（如從設備樹中獲取設備信息）。這樣就相當于驅動只負責驅動，設備（信息）只負責設備，想辦法將兩者進行匹配即可，來做這個匹配工作的就是總線，這就構成了 Linux 中的 總線-驅動-設備 模型。結構圖如下：
1.2、platform 平臺驅動模型
? ? ? ? 上面我們講做設備驅動的分離，得到 總線-驅動-設備 模型，這個總線就是我平常所說的 I2C、SPI、USB 等總線。但問題是有些設備是不需要通過某一跟總線的，這是就引入了 platform 總線。
????????這里需要注意的是，platform 總線是區(qū)別于 USB、SPI、I2C 這些總線的虛擬總線。說它虛擬是因為 SoC 與一些外設如 LED、定時器、蜂鳴器是通過內存的尋址空間來進行尋址的，所以 CPU 與這些設備通信壓根就不需要總線，那么硬件上也就沒有這樣一個總線。但內核有對這些設備做統(tǒng)一管理的需求，所以就對這些直接通過內存尋址的設備虛擬了一條 platform 總線，所有直接通過內存尋址的設備都映射到這條虛擬總線上。
? ? ? ? platform 總線的優(yōu)點：
? ? ? ? 1、通過 platform 總線，可以遍歷所有掛載在?platform 總線上的設備；
? ? ? ? 2、實現(xiàn)設備和驅動的分離，通過 platform 總線，設備和驅動是分開注冊的，因為有?probe 函數(shù)，可以隨時檢測與設備匹配的驅動，匹配成功就會把這個驅動向內核注冊；
? ? ? ? 3、一個驅動可供同類的幾個設備使用，這個功能的實現(xiàn)是因為驅動注冊過程中有一個遍歷設備的操作。? ? ??
2、platform 框架
2.1、platform 總線
? ? ? ? Linux 內核用 bus_type 結構體來表示總線，我們所用的 I2C、SPI、USB 都是用這個結構體來定義的。該結構體如下：
/* include/linux/device.h */
struct bus_type {
const char *name; /* 總線名字 */
const char *dev_name;
struct device *dev_root;
struct device_attribute *dev_attrs;
const struct attribute_group **bus_groups; /* 總線屬性 */
const struct attribute_group **dev_groups; /* 設備屬性 */
const struct attribute_group **drv_groups; /* 驅動屬性 */
int (*match)(struct device *dev, struct device_driver *drv); /* 設備驅動匹配函數(shù) */
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
int (*probe)(struct device *dev);
int (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*online)(struct device *dev);
int (*offline)(struct device *dev);
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
const struct dev_pm_ops *pm;
const struct iommu_ops *iommu_ops;
struct subsys_private *p;
struct lock_class_key lock_key;
};
? ? ? ? ?platform 總線是 bus_type 類型的常量，之所以說它是常量是因為這個變量已經被 Linux 內核賦值好了，其結構體成員對應的函數(shù)也已經在內核里面寫好。
定義如下：
/* drivers/base/platform.c */
struct bus_type platform_bus_type = {
.name = "platform",
.dev_groups = platform_dev_groups,
.match = platform_match, /* 匹配函數(shù) */
.uevent = platform_uevent,
.pm = &platform_dev_pm_ops,
};
? ? ? ? platform_bus_type 中的 platform_match 就是我們前面所說的做驅動和設備匹配的函數(shù)，該函數(shù)定義如下：
/* drivers/base/platform.c */
static int platform_match(struct device *dev, struct device_driver *drv)
{
struct platform_device *pdev = to_platform_device(dev);
struct platform_driver *pdrv = to_platform_driver(drv);
/*When driver_override is set,only bind to the matching driver*/
if (pdev->driver_override)
return !strcmp(pdev->driver_override, drv->name);
/* 設備樹OF類型匹配
驅動基類的 of_match_table 里的 compatible 匹配表與設備樹
每一個設備節(jié)點的 compatible 屬性作比較，有相同就表示匹配成功 */
if (of_driver_match_device(dev, drv))
return 1;
/* ACPI 匹配 */
if (acpi_driver_match_device(dev, drv))
return 1;
/* id_table 匹配
platform 驅動里的 id_table 數(shù)組會保存很多 id 信息 */
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
/* name 匹配
直接粗暴比較platform 的驅動和設備里面的 name 信息 */
return (strcmp(pdev->name, drv->name) == 0);
}
? ? ? ? 這個匹配函數(shù)什么時候用，在哪里用，我們不妨先留一個懸念。
2.2、platform 驅動
2.2.1、platform 驅動定義
? ? ? ? platform 驅動用結構體 platform_driver 來表示，該結構體內容為：
/* include/linux/platform_device.h */
struct platform_driver {
int (*probe)(struct platform_device *); /* platform驅動和platform設備匹配后會執(zhí)行這個probe函數(shù) */
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*resume)(struct platform_device *);
struct device_driver driver; /* 驅動基類 */
const struct platform_device_id *id_table; /* id_table表 */
bool prevent_deferred_probe;
};
? ? ? ? ?platform_driver 中?const struct platform_device_id *id_table 是 id_table 表，在 platform 總線匹配驅動和設備時?id_table 表匹配法時使用的，這個?id_table 表其實是一個數(shù)組，里面的每個元素類型都為?platform_device_id，platform_device_id 是一個結構體，內容如下：
struct platform_device_id {
char name[PLATFORM_NAME_SIZE];
kernel_ulong_t driver_data;
};
? ? ? ? platform_driver 中?driver 是一個驅動基類，相當于驅動具有的最基礎的屬性，在不同總線下具有的屬性則存放在?platform_driver 結構體下。
? ? ? ? 驅動基類結構體?device_driver 內容為：
/* include/linux/device.h */
struct device_driver {
const char *name; /* platform 總線來匹配設備與驅動的第四種方
法就是直接粗暴匹配兩者的 name 字段 */
struct bus_type *bus;
struct module *owner;
const char *mod_name;
bool suppress_bind_attrs;
const struct of_device_id *of_match_table; /* 采用設備樹時驅動使用的的匹配表 */
const struct acpi_device_id *acpi_match_table;
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);
int (*suspend) (struct device *dev, pm_message_t state);
int (*resume) (struct device *dev);
const struct attribute_group **groups;
const struct dev_pm_ops *pm;
struct driver_private *p;
};
? ? ? ? ?driver 中 of_match_table 也是一個匹配表，這個匹配表是 platform 總線給驅動和設備做匹配時使用設備樹匹配時用的，也是一個數(shù)組，數(shù)組元素都為?of_device_id 類型，該類型結構體如下：
/* include/linux/mod_devicetable.h */
struct of_device_id {
char name[32];
char type[32];
char compatible[128]; /* 使用設備樹匹配時就是把設備節(jié)點的 compatible 屬性值和 of_match_table 中
每個項目的這個 compatible 作比較，如果有相等的就表示設備和驅動匹配成功 */
const void *data;
};
2.2.2、platform 驅動注冊
? ? ? ? 用?platform_driver 結構體定義好 platform 驅動后，用 platform_driver_register 函數(shù)向 Linux 內核注冊 platform 驅動，函數(shù)大致流程如下：
platform_driver_register (drv)
-> __platform_driver_register
-> drv->driver.probe = platform_drv_probe; /* 把 platform_drv_probe 這個函數(shù)賦給
platform 驅動里的驅動基類 drier 的 probe 函數(shù) */
-> driver_registe (&drv->driver) /* 向 Linux 內核注冊驅動基類 driver */
-> ......
-> drv->driver->probe /* 最終執(zhí)行驅動基類 driver 的 probe 函數(shù)，
其實就是上面給的 platform_drv_probe 函數(shù) */
-> platform_drv_probe
-> drv->probe /* platform_drv_probe 函數(shù)又會執(zhí)行
platform 驅動 drv 的 probe 函數(shù) */
? ? ? ? 上面的分析中從 driver_register (&drv->driver) 到 drv->driver->probe 這一步我們用省略號代替了，現(xiàn)在來做一下分析：
driver_register(&drv->driver)
-> bus_add_driver /* 向總線添加驅動 */
-> driver_attach
-> bus_for_each_dev /* 查找總線下每一個設備，即遍歷操作 */
-> __driver_attach /* 每個設備都調用此函數(shù) */
-> driver_match_device /* 檢查是否匹配 */
-> 調用bus下的match匹配函數(shù)
-> driver_probe_device /* 匹配成功后執(zhí)行此函數(shù) */
-> really_probe
-> drv->probe /* 執(zhí)行drv下的probe函數(shù) */
? ? ? ? 根據(jù)?driver_register 函數(shù)流程，我們就知道了總線的 match 匹配函數(shù)會在這里遍歷使用，這就回答了我們之前留下的一個問題：總線 match 函數(shù)在哪里用，一旦匹配成功就會進入到驅動的 probe 函數(shù)。?
????????根據(jù) platform_driver_register 函數(shù)流程，我們可以得出一個結論：向 Linux 內核注冊 platform driver 過程里面會有一個遍歷驅動和設備匹配的過程，匹配成功后最終會執(zhí)行 platform driver 的 probe 函數(shù)，過程中 的驅動基類 driver 的 probe 函數(shù)和 platform_drv_probe 函數(shù)都是達到這個目的的中轉函數(shù)而已。
? ? ? ? 值得注意的是，最終會執(zhí)行的 platform driver 的 probe 函數(shù)是由我們來寫的，所以主動權又回到我們手里。
2.3、platform 設備
2.3.1、platform 設備定義
? ? ? ? 如果我們用的 Linux 版本支持設備樹，那就在設備樹中去描述設備，如果不支持設備樹，就要定義好 platform 設備。這里我們需要考慮的一個點是，總線下的匹配函數(shù) match 在做匹配時是先設備樹匹配，然后 id_table 表匹配，然后才是 name 字段匹配。支持設備樹時，直接在設備樹節(jié)點里面改設備信息，內核啟動時會自動遍歷設備樹節(jié)點，匹配成功就會自動生成一個 platform_device，給下一步來使用。不是設備樹的話，這個 platform_device 就是由開發(fā)者來寫。
????????這里我們先不用設備樹，自己來定義 platform 設備。platform 設備用 platform_device 結構體來表示，該結構體定義如下：
/* include/linux/platform_device.h */
struct platform_device {
const char *name; /* 設備名，得和對應的 platform 驅動的 name 一樣，
否則設備就無法匹配到對應驅動 */
int id;
bool id_auto;
struct device dev;
u32 num_resources;
struct resource *resource;
const struct platform_device_id *id_entry;
char *driver_override; /* Driver name to force a match */
/* MFD cell pointer */
struct mfd_cell *mfd_cell;
/* arch specific additions */
struct pdev_archdata archdata;
};
2.4、platform 匹配過程
? ? ? ? platform 總線對驅動和設備的匹配過程其實上面零零碎碎也已經講的差不多了，現(xiàn)在我們匯總起來在過一遍。
? ? ? ? 前面也說過，總線下的驅動和設備的匹配是通過總線下的 match 函數(shù)來實現(xiàn)的，不同的總線對應的 match 函數(shù)肯定不一樣，這個我們不用管，內核都會寫好。我們所用的 platform 總線對應的 match 函數(shù)是 platform_match 函數(shù)，分析一下這個函數(shù)：
platform_match
-> of_driver_match_device /* 設備樹匹配 */
-> acpi_driver_match_device /* ACPI 匹配 */
-> platform_match_id /* platform_driver->id_table 匹配 */
-> strcmp(pdev->name, drv->name) /* name 匹配 */
? ? ? ? ?通過對上面匹配函數(shù)的一個簡單分析，我們知道匹配函數(shù)做匹配的順序是先匹配設備樹，然后匹配 id_table 表，然后才是暴力匹配 name 字段。對于支持設備樹的 Linux 版本，我們一上來做設備樹匹配就完事。不支持設備樹時，我們就得定義 platform 設備，再用 id_tabale 表或 name 匹配，一般情況下都是選用 name 匹配。
? ? ? ? 現(xiàn)在我們來具體看一下設備樹條件下的匹配過程：
of_driver_match_device /* of函數(shù)一般是用于設備樹，這也算給了我們提示 */
-> of_match_device (drv->of_match_table, dev)
-> of_match_node
-> __of_match_node
-> __of_device_is_compatible
-> __of_find_property(device, "compatible", NULL) /* 取出compatible屬性值 */
? ? ? ? 看上面的分析我們就知道了這個匹配過程最終是驅動基類的 of_match_table 里的 compatible 去設備樹節(jié)點里面的?compatible 屬性作比較。這個就是把設備樹與 platform 總線串起來的一個機理，從而實現(xiàn)了在設備樹對應節(jié)點里面寫設備信息，驅動另外單獨寫的目的，也就是我們前面講的驅動分離。
?3、總結
? ? ? ? 在具體的開發(fā)過程中我們并不需要真的去寫一個 platform 總線模型，內核中都已經給我們定義好了。我們對 platform 總線模型的分析主要是搞清楚如何將驅動和設備匹配的，即當我們插入設備是如何找到對應驅動或插入驅動如何找到對應設備的，并最終調用 probe 函數(shù)。其實不管是先有驅動后有設備、還是先有設備后有驅動，最終匹配成功后第一件事都是執(zhí)行驅動的 probe 函數(shù)，所以我們盡可放心的忽略中間曲折的情感糾葛，直接把注意力放在最終的 probe 函數(shù)。
到此這篇關于Linux驅動之platform總線詳解的文章就介紹到這了,更多相關Linux驅動platform總線內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
這篇文章主要介紹了Centos7 格式化分區(qū)并掛載的實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-12-12
大家好，本篇文章主要講的是Linux環(huán)境下查看日志文件命令詳解，感興趣的同學趕快來看一看吧，對你有幫助的話記得收藏一下，方便下次瀏覽2021-12-12
這篇文章主要介紹了Linux MySQL忘記root密碼解決方案,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-05-05
centos下yum搭建安裝linux+apache+mysql+php環(huán)境的方法
這篇文章主要介紹了centos下yum搭建安裝linux+apache+mysql+php環(huán)境的方法,本文分步驟給大家介紹的非常詳細，具有參考借鑒價值，需要的朋友可以參考下2016-10-10
本篇文章主要介紹了CentOS 7安裝Mysql并設置開機自啟動的方法，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-02-02
你是否會和我一樣經常碰到這樣的情景：在VIM中編輯了一個系統(tǒng)配置文件，當需要保存時才發(fā)現(xiàn)當前的用戶對該文件沒有寫入的權限。這個時候就需要強制保存只讀類型文件的方法了，這篇文章就介紹了Vim強制保存只讀類型文件的方法,需要的朋友可以參考借鑒，下面來一起看看吧。2017-01-01
下面小編就為大家?guī)硪黄狶inux配置VSFTP服務器的方法。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-12-12
解決centos7安裝nginx后無conf.d目錄或conf.d目錄下無default.conf文件問題
這篇文章主要介紹了解決centos7安裝nginx后無conf.d目錄或conf.d目錄下無default.conf文件問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-01-01
這篇文章主要介紹了Linux中fuser命令用法詳解,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-06-06
這篇文章主要介紹了centos下samba文件夾共享服務器配置詳解，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-02-02