深入決議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	= https://www.cnblogs.com/embInn/p/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內置了大量豐富的各類設備介面，這些介面往往都是通過處理器內部總線進行直接尋址的，這型別的設備幾乎都是通過平臺設備及驅動模型進行抽象實施的，所以深入理解平臺設備/平臺設備驅動模型，無疑對開發此類設備驅動程式大有助益，
文章出自微信公眾號：嵌入式客堆疊，由于時間關系，博客可能無法及時更新，最新內容，請關注本人公眾號,嚴禁商業使用，違法必究

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/1783.html

標籤：嵌入式

上一篇：TX2i設備樹SPI驅動

下一篇：低電壓SRAM的重要性