吉林省建设安全信息网官网_深圳seo网络推广_企业网站推广的方法有_营销推广公司

🔍

B站相应的视屏教程：
📌 内核：博文+视频 - 总线驱动模型实战全解析
敬请关注，记得标为原始粉丝。

---

🔧

📍 一、目标与回顾

在上篇《理论篇》中，我们从软件工程角度，解释了 设备模型是如何模拟运行时“适配器”模式，解决了设备与驱动之间的解耦问题。

本篇我们进入实战环节，围绕 Linux 内核常用的 platform_driver 驱动注册机制展开，结合典型驱动代码（如 LCDIF 控制器、GPIO 控制器等），剖析：

• 内核中设备模型如何实现“适配”
• of_device_id 与 device_node 如何进行匹配
• 驱动的生命周期管理如何与设备结构融合

🚀 二、平台驱动模型本质 = 注册适配器 + 匹配设备

我们以一个 LCDIF 控制器为例（NXP i.MX8M 平台上的 imx-lcdif 驱动），其设备模型使用 platform_device + platform_driver 构建，典型代码如下：

1️⃣ 设备树描述（设备端）

lcdif1: lcd-controller@32e80000 {compatible = "fsl,imx8mp-lcdif1";reg = <0x32e80000 0x10000>;interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;clocks = <&clk IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT>;status = "okay";
};

2️⃣ 驱动端结构（驱动适配器）

static const struct of_device_id lcdif_of_match[] = {{ .compatible = "fsl,imx8mp-lcdif1" },{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lcdif_of_match);static struct platform_driver lcdif_driver = {.driver = {.name = "imx-lcdif",.of_match_table = lcdif_of_match,},.probe = lcdif_probe,.remove = lcdif_remove,
};

✅ 核心机制解析

• of_match_table 中的 compatible 会被内核在启动时与设备树节点对比；
• 匹配成功后，调用 .probe() 函数，传入已经构造好的 platform_device 对象；
• 此对象即运行时绑定的 “设备实例”；
• 驱动作为 “适配器”，根据设备提供的 reg、中断、clock 等信息完成初始化。

这就是运行时“适配器机制”的核心体现。

---

📊 三、运行机制流程图

设备树中的节点↓
of_platform_populate() → 创建 platform_device↓
bus_register(&platform_bus_type)↓
platform_driver_register() → 注册适配器↓
device_register() → 与 device_match() 匹配↓
成功匹配：调用 driver.probe(dev)

这一系列链条清晰地展示了驱动模型的运行时“查找-匹配-适配-绑定”过程。

---

📌 四、核心结构解读：如何自动适配？

1️⃣ platform_device 是什么？

是内核为设备节点自动生成的结构，核心结构如下：

struct platform_device {const char *name;int id;struct device dev;resource *resource;unsigned int num_resources;
};

其内部的 dev.of_node 指向设备树的 device_node，供后续匹配与资源解析。

2️⃣ platform_driver 是什么？

是驱动作为“适配器”的载体，关键字段是：

struct platform_driver {int (*probe)(...);const struct of_device_id *of_match_table;...struct device_driver driver;
};

3️⃣ 匹配过程：of_match_device()

const struct of_device_id *of_match_device(const struct of_device_id *matches, const struct device *dev)

• 这个函数会遍历 of_match_table，与 dev->of_node 中的 compatible 属性进行匹配；
• 如果匹配成功，则调用 probe() 完成驱动初始化。

---

🎯 五、实战代码示例：LCDIF 控制器

我们来看 lcdif_probe() 函数中是如何从设备树中获取资源的：

static int lcdif_probe(struct platform_device *pdev)
{struct resource *res;void __iomem *base;struct clk *pix_clk;int irq;res = platform_get_resource(pdev, IORESOURCE_MEM, 0);base = devm_ioremap_resource(&pdev->dev, res);irq = platform_get_irq(pdev, 0);pix_clk = devm_clk_get(&pdev->dev, "pix");clk_prepare_enable(pix_clk);// 完成寄存器初始化、中断注册等...
}

✅ 对应的设备树

lcdif1: lcd-controller@32e80000 {compatible = "fsl,imx8mp-lcdif1";reg = <0x32e80000 0x10000>;interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;clocks = <&clk IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT>;status = "okay";
};

⛓️ 完整的匹配链条：

驱动结构	设备树字段
of_match_table	compatible = "fsl,xxx"
platform_get_resource()	reg = <...>
platform_get_irq()	interrupts = <...>
devm_clk_get()	clocks = <...>

一一对应，驱动适配了设备结构，这就是适配器的运行时体现。

---

⚠️ 六、常见问题与经验总结

❓ 为什么不是所有驱动都用 platform_driver？

因为：

• platform_driver 是为“无标准总线的设备”准备的通用驱动模型；
• 对于有标准总线的设备（如 I2C、SPI、PCI），更推荐使用 i2c_driver、spi_driver 等专用模型；
• 它们依赖于 i2c_device_id 与 i2c_register_driver() 实现专属适配机制；
• 内核会通过 i2c-core 探测机制进行总线驱动匹配。

❗ platform_driver 和 i2c_driver 没有直接联系，但都属于统一的设备模型框架，挂载在 /sys/bus/ 中不同的 bus_type 下。

---

🔍 七、设备模型与适配器模式的再对比

对应关系	软件适配器模式	Linux 设备模型
Adapter 类	platform_driver	适配设备信息，完成初始化
Adaptee 类	platform_device	提供 reg / irq / clocks
接口 contract	probe + resource 获取	统一的注册与匹配流程
适配时机	运行时	开机或热插拔时

Linux 设备模型将设备信息与驱动代码 解耦，实现了运行时适配，这是复杂系统中降低耦合度的关键模式之一。

---

✅ 八、总结

本篇我们围绕 platform_driver 驱动模型，分析了其在 Linux 内核中如何扮演“运行时适配器”的角色。通过具体示例（LCD 控制器），我们讲清了：

• 驱动如何通过 of_match_table 与设备树匹配；
• 如何获取 reg、irq、clock 等资源；
• 运行时自动匹配机制的工作原理；
• 设备模型与软件适配器模式的深层对应关系。

在未来的驱动开发中，理解设备模型背后的“适配思想”，将极大提升我们组织代码的能力与模块化程度。

---