閱讀本文，建議先讀：學(xué)Linux驅(qū)動：應(yīng)先了解總線驅(qū)動模型

上文點擊即可閱讀。注：代碼分析基于linux-5.4.31

為什么有Platform_driver

前文談到的總線驅(qū)動模型（注這個圖是照著bootlin的文檔繪制的）：

同時，根據(jù)代碼分析其基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)框架關(guān)系如下（UML關(guān)系并不嚴謹，僅為理解方便）：

可見驅(qū)動程序的模型分層有一層總線基礎(chǔ)層，那么對于嵌入式開發(fā)領(lǐng)域而言，有很多SOC芯片內(nèi)置了各種外設(shè)，并比如LCD，UART、audio、攝像頭口等等，并沒有總線。為了統(tǒng)一驅(qū)動架構(gòu)抽象，所以引入了platform bus這個虛擬的總線模型。做過嵌入式開發(fā)的人應(yīng)該都有體會，這類設(shè)備在嵌入式系統(tǒng)中非常多，所以在研究具體某類設(shè)備的驅(qū)動開發(fā)之前，有必要研究platform 設(shè)備的驅(qū)動模型。在強調(diào)一下這個是統(tǒng)一在總線驅(qū)動模型這個體系內(nèi)的。

驅(qū)動模型的實現(xiàn)

定義在./include/linux/platform_device.h中，來梳理一下這些數(shù)據(jù)結(jié)構(gòu)間的關(guān)系：

• platform_device 用于抽象平臺設(shè)備
• platform_driver 用于抽象匹配平臺設(shè)備對應(yīng)的驅(qū)動程序
• 通過繼承演化關(guān)系分析，platform_device/platform_driver 仍然統(tǒng)一于總線驅(qū)動模型，只是虛擬出來了一條platform bus這樣一條虛擬總線。
• platform_bus在哪里實現(xiàn)的呢？該模塊的實現(xiàn)位于./driver/base/platform.c中

struct device platform_bus = {
 .init_name = "platform",
};

• platform.c導(dǎo)出了一系列內(nèi)核全局操作接口集：

EXPORT_SYMBOL_GPL(platform_bus);
EXPORT_SYMBOL_GPL(__platform_driver_register);
EXPORT_SYMBOL_GPL(__platform_driver_probe);
EXPORT_SYMBOL_GPL(platform_get_resource_byname);
EXPORT_SYMBOL_GPL(platform_get_irq_byname);
....

• 那么既然這條總線并不存在，往往并不能實現(xiàn)設(shè)備枚舉、熱插拔等功能。

• 既然不能利用總線自動枚舉，那么底層又是怎么玩的呢？實際上可選的有這樣幾種方式

• 通過內(nèi)核代碼靜態(tài)描述實現(xiàn)
• 通過設(shè)備樹進行匹配加載
• BIOS ACPI表(X86/PC體系)

• 平臺設(shè)備是通常在系統(tǒng)中顯示為自治實體的設(shè)備。這包括基于舊端口的設(shè)備和到外圍總線的主機橋接，以及集成到片上系統(tǒng)平臺中的大多數(shù)控制器。它們通常的共同點是從CPU總線直接尋址。很少有platform_device通過某種其他類型的總線的一部分連接的。但其寄存器仍將直接可尋址。

設(shè)備探測

• probe()通常應(yīng)該驗證指定的設(shè)備硬件確實存在;有時平臺設(shè)置代碼不能確定。該函數(shù)用于檢測可以使用設(shè)備資源，包括時鐘和設(shè)備platform_data。
• 設(shè)備的注冊則是通過下面函數(shù)實現(xiàn)

int platform_driver_register(struct platform_driver *drv);

設(shè)備命令以及綁定

• platform_device.dev.bus_id 設(shè)備名由兩個部分組成
• platform_device.name 用于驅(qū)動匹配
• platform_device.id 設(shè)備實例號，或者用“-1”表示只有一個實例
• 如"serial/0“ 表示 bus_id "serial.0"，"serial/3“ 表示 bus_id "serial.3"
• 驅(qū)動程序綁定由驅(qū)動程序核心自動執(zhí)行，在發(fā)現(xiàn)設(shè)備和驅(qū)動程序之間的匹配之后調(diào)用驅(qū)動程序probe()。如果probe()成功，驅(qū)動程序和設(shè)備將像往常一樣綁定。有三種不同的方法來找到這樣的匹配:
• 每當(dāng)注冊一個設(shè)備時，就會檢查該總線的驅(qū)動程序是否匹配。平臺設(shè)備應(yīng)該在系統(tǒng)啟動時盡早注冊.
• 當(dāng)使用platform_driver_register()注冊一個驅(qū)動程序時，將檢查總線上所有未綁定的設(shè)備是否匹配。驅(qū)動程序通常在引導(dǎo)期間稍后注冊，或者通過模塊加載注冊。
• 使用platform_driver_probe()注冊驅(qū)動程序與使用platform_driver_register()一樣，不同的是，如果以后有其他設(shè)備注冊，驅(qū)動程序不會被探測。

資源機制

• 每個由特定驅(qū)動程序管理的設(shè)備通常使用不同的硬件資源:I/O寄存器地址、DMA通道、IRQ線路等。
• struct resource就是用于抽象描述驅(qū)動程序需要用到的硬件資源，struct resource 被包進platform_device，實現(xiàn)與 struct platform_device關(guān)聯(lián)。
• 允許驅(qū)動程序被實例化為多個功能類似的設(shè)備，但具有不同的地址、irq等。
• 硬件資源如時針、IO口等的分配現(xiàn)在基本基于設(shè)備樹，對于設(shè)備樹這里不展開，后面有機會總結(jié)分享，這里舉個栗子：

uart0: serial@44e09000 {
    compatible = "ti,omap3-uart";
    ti,hwmods = "uart1";
    clock-frequency = <48000000>;
    reg = <0x44e09000 0x2000>;
    interrupts = <72>;
    status = "disabled";
};

platform_driver實例

以samsung.c 串口驅(qū)動程序為例：

/*兼容匹配表*/
static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 {
  .name  = "s3c2410-uart",
  .driver_data = S3C2410_SERIAL_DRV_DATA,
 }, {
  .name  = "s3c2412-uart",
  .driver_data = S3C2412_SERIAL_DRV_DATA,
 }, {
  .name  = "s3c2440-uart",
  .driver_data = S3C2440_SERIAL_DRV_DATA,
 }, {
  .name  = "s3c6400-uart",
  .driver_data = S3C6400_SERIAL_DRV_DATA,
 }, {
  .name  = "s5pv210-uart",
  .driver_data = S5PV210_SERIAL_DRV_DATA,
 }, {
  .name  = "exynos4210-uart",
  .driver_data = EXYNOS4210_SERIAL_DRV_DATA,
 }, {
  .name  = "exynos5433-uart",
  .driver_data = EXYNOS5433_SERIAL_DRV_DATA,
 },
 { },
};
MODULE_DEVICE_TABLE(platform, s3c24xx_serial_driver_ids);

#ifdef CONFIG_OF
/*設(shè)備樹對應(yīng)解析匹配表*/
static const struct of_device_id s3c24xx_uart_dt_match[] = {
 { .compatible = "samsung,s3c2410-uart",
  .data = (void *)S3C2410_SERIAL_DRV_DATA },
 { .compatible = "samsung,s3c2412-uart",
  .data = (void *)S3C2412_SERIAL_DRV_DATA },
 { .compatible = "samsung,s3c2440-uart",
  .data = (void *)S3C2440_SERIAL_DRV_DATA },
 { .compatible = "samsung,s3c6400-uart",
  .data = (void *)S3C6400_SERIAL_DRV_DATA },
 { .compatible = "samsung,s5pv210-uart",
  .data = (void *)S5PV210_SERIAL_DRV_DATA },
 { .compatible = "samsung,exynos4210-uart",
  .data = (void *)EXYNOS4210_SERIAL_DRV_DATA },
 { .compatible = "samsung,exynos5433-uart",
  .data = (void *)EXYNOS5433_SERIAL_DRV_DATA },
 {},
};
MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
#endif
/*串口設(shè)備驅(qū)動實體*/
static struct platform_driver samsung_serial_driver = {
 .probe  = s3c24xx_serial_probe,
 .remove  = s3c24xx_serial_remove,
 .id_table = s3c24xx_serial_driver_ids,
 .driver  = {
  .name = "samsung-uart",
  .pm = SERIAL_SAMSUNG_PM_OPS,
  .of_match_table = of_match_ptr(s3c24xx_uart_dt_match),
 },
};

總結(jié)一下

對于做嵌入式Linux驅(qū)動開發(fā)，個人體會是先對總線驅(qū)動模型有一個相對清晰的概念認識會比較好，而平臺設(shè)備以及平臺設(shè)備驅(qū)動模型同樣是衍生于總線驅(qū)動模型，這樣從體系結(jié)構(gòu)上就變得相對統(tǒng)一了。平臺設(shè)備及驅(qū)動在嵌入式系統(tǒng)里大量應(yīng)用，很多SOC內(nèi)置了大量豐富的各類設(shè)備接口，這些接口往往都是通過處理器內(nèi)部總線進行直接尋址的，這類型的設(shè)備幾乎都是通過平臺設(shè)備及驅(qū)動模型進行抽象實施的，所以深入理解平臺設(shè)備/平臺設(shè)備驅(qū)動模型，無疑對開發(fā)此類設(shè)備驅(qū)動程序大有助益。