深刻解析Linux Platform_device 及驅動

[導讀] 前文分析了Linux設備驅動的驅動模型，本文來聊聊Platform_driver/Platform_device這個類。作嵌入式Linux的驅動，這個也是繞不開的，因此來學習分析總結一下。

上文閱讀：

注：代碼分析基於linux-5.4.31

爲何有Platform_driver

前文談到的總線驅動模型（注這個圖是照着bootlin的文檔繪製的）：

同時，根據代碼分析其基礎數據結構框架關係以下（UML關係並不嚴謹，僅爲理解方便）：

可見驅動程序的模型分層有一層總線基礎層，那麼對於嵌入式開發領域而言，有不少SOC芯片內置了各類外設，並好比LCD，UART、audio、攝像頭口等等，並無總線。爲了統一驅動架構抽象，因此引入了platform bus這個虛擬的總線模型。作過嵌入式開發的人應該都有體會，這類設備在嵌入式系統中很是多，因此在研究具體某類設備的驅動開發以前，有必要研究platform 設備的驅動模型。在強調一下這個是統一在總線驅動模型這個體系內的。

驅動模型的實現

定義在./include/linux/platform_device.h中，來梳理一下這些數據結構間的關係：

• platform_device 用於抽象平臺設備
• platform_driver 用於抽象匹配平臺設備對應的驅動程序
• 經過繼承演化關係分析，platform_device/platform_driver 仍然統一於總線驅動模型，只是虛擬出來了一條platform bus這樣一條虛擬總線。
• platform_bus在哪裏實現的呢？該模塊的實現位於./driver/base/platform.c中

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

• platform.c導出了一系列內核全局操做接口集：

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);
....

• 那麼既然這條總線並不存在，每每並不能實現設備枚舉、熱插拔等功能。

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

  • 經過內核代碼靜態描述實現
  • 經過設備樹進行匹配加載
  • BIOS ACPI表(X86/PC體系)

• 平臺設備是一般在系統中顯示爲自治實體的設備。 這包括基於舊端口的設備和到外圍總線的主機橋接，以及集成到片上系統平臺中的大多數控制器。 它們一般的共同點是從CPU總線直接尋址。 不多有platform_device經過某種其餘類型的總線的一部分鏈接的。 但其寄存器仍將直接可尋址。

設備探測

• probe()一般應該驗證指定的設備硬件確實存在;有時平臺設置代碼不能肯定。該函數用於檢測可使用設備資源，包括時鐘和設備platform_data。
• 設備的註冊則是經過下面函數實現

int platform_driver_register(struct platform_driver *drv);

設備命令以及綁定

• platform_device.dev.bus_id 設備名由兩個部分組成
  • platform_device.name 用於驅動匹配
  • platform_device.id 設備實例號，或者用「-1」表示只有一個實例
  • 如"serial/0「 表示 bus_id "serial.0"，"serial/3「 表示 bus_id "serial.3"
• 驅動程序綁定由驅動程序核心自動執行，在發現設備和驅動程序之間的匹配以後調用驅動程序probe()。若是probe()成功，驅動程序和設備將像往常同樣綁定。有三種不一樣的方法來找到這樣的匹配:
  • 每當註冊一個設備時，就會檢查該總線的驅動程序是否匹配。平臺設備應該在系統啓動時儘早註冊.
  • 當使用platform_driver_register()註冊一個驅動程序時，將檢查總線上全部未綁定的設備是否匹配。驅動程序一般在引導期間稍後註冊，或者經過模塊加載註冊。
  • 使用platform_driver_probe()註冊驅動程序與使用platform_driver_register()同樣，不一樣的是，若是之後有其餘設備註冊，驅動程序不會被探測。

資源機制

• 每一個由特定驅動程序管理的設備一般使用不一樣的硬件資源:I/O寄存器地址、DMA通道、IRQ線路等。
• struct resource就是用於抽象描述驅動程序須要用到的硬件資源，struct resource 被包進platform_device，實現與 struct platform_device關聯。
• 容許驅動程序被實例化爲多個功能相似的設備，但具備不一樣的地址、irq等。
• 硬件資源如時針、IO口等的分配如今基本基於設備樹，對於設備樹這裏不展開，後面有機會總結分享，這裏舉個栗子：

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

platform_driver實例

以samsung.c 串口驅動程序爲例：

/*兼容匹配表*/
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
/*設備樹對應解析匹配表*/
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
/*串口設備驅動實體*/
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),
	},
};

總結一下

對於作嵌入式Linux驅動開發，我的體會是先對總線驅動模型有一個相對清晰的概念認識會比較好，而平臺設備以及平臺設備驅動模型一樣是衍生於總線驅動模型，這樣從體系結構上就變得相對統一了。平臺設備及驅動在嵌入式系統裏大量應用，不少SOC內置了大量豐富的各種設備接口，這些接口每每都是經過處理器內部總線進行直接尋址的，這類型的設備幾乎都是經過平臺設備及驅動模型進行抽象實施的，因此深刻理解平臺設備/平臺設備驅動模型，無疑對開發此類設備驅動程序大有助益。
文章出自微信公衆號：嵌入式客棧，因爲時間關係，博客可能沒法及時更新，最新內容，請關注本人公衆號,嚴禁商業使用，違法必究