Day 8 上篇:深入理解 Linux 驱动模型中的平台驱动与总线驱动

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


在 Linux 内核驱动模型中,设备与驱动的组织方式不是随意堆砌,而是基于清晰的分类逻辑进行架构设计的。最核心的架构基础是“设备模型”(Device Model),而在此模型之上,各类驱动通过“平台驱动模型”与“总线驱动模型”协同运作,实现灵活、高度可扩展的硬件抽象层。

本篇将作为《Day 8》的上篇内容,系统性讲解平台驱动与总线驱动的理论框架、分类方式、匹配机制及其在设备树支持下的应用方法,帮助你全面理解驱动模型的本质与结构基础。


一、Linux 设备模型简介:统一的抽象基础

从 Linux v2.6 内核开始,引入了统一的“设备模型”(Device Model),核心目标是:以统一的方式管理设备与驱动的关系,实现热插拔、自动挂载、sysfs 信息导出、电源管理等功能。

设备模型的三个核心组成:

  • struct device:表示一个硬件设备;
  • struct device_driver:表示该设备的驱动;
  • struct bus_type:用于连接设备与驱动,形成“设备-驱动总线”。

设备模型本身并不决定设备的分类方式,而是提供统一接口,不同的子系统(如平台设备、I2C、SPI、PCI)根据硬件体系构建在它之上。


二、驱动模型的分类逻辑:平台与总线驱动

1. 平台驱动模型(Platform Driver Model)

在这里插入图片描述

平台驱动模型(Platform Driver Model)主要用于描述无法通过标准枚举机制自动发现的设备。如 SoC 内部的控制器、片上外设(LCD 控制器、PWM、I2C 控制器等)。

核心结构:

  • struct platform_device
  • struct platform_driver
  • platform_bus_type

匹配机制:

  • 驱动中注册 platform_driver
  • DTS 中节点生成 platform_device
  • 匹配通过 of_match_tabledriver.name 对比设备节点 compatiblename 属性

适用场景:

  • 片上外设(SoC peripherals)
  • 固定拓扑结构的设备(不支持热插拔)

2. 总线驱动模型(Bus Driver Model)

在这里插入图片描述

总线驱动模型 是针对可被标准总线发现和枚举的设备类型构建的驱动框架,如:

  • i2c_driver:用于挂在 I2C 总线上的设备
  • spi_driver:用于 SPI 总线设备
  • pci_driver:PCI/PCIe 设备
  • usb_driver:USB 外设

这些总线本身都是 struct bus_type 的实例。每种总线都维护了一个自己的设备与驱动结构,提供标准化的 probe 入口与资源获取方式。

匹配机制:

  • 子设备通过 of_device_id(或 ACPI)与 i2c_driver 中的匹配表比对
  • 驱动通过总线核心进行绑定调用 probe

适用场景:

  • 支持自动枚举或扫描的外部总线(可热插拔或可动态挂载设备)
  • 芯片级外设(如 I2C、SPI 的从设备)

三、平台驱动与总线驱动的结构对比

特性平台驱动(platform_driver)总线驱动(i2c_driver 等)
设备定义方式platform_devicei2c_client 等设备结构
注册方式platform_driver_register()i2c_add_driver()
匹配依据compatible / namecompatible + 地址(reg)
子系统入口platform_bus_typei2c_bus_type
使用场景SoC 内部固定设备可枚举的标准外设
资源获取方式platform_get_resource()client->irqregmap
DTS 节点结构controller@base + 子节点controller + reg-based 子节点

四、设备模型下的总线分类汇总

Linux 中存在众多 bus_type 类型,每一种都对应一套设备与驱动注册框架。常见示例如下:

/sys/bus/
├── i2c            ← 对应 i2c_driver
├── spi            ← 对应 spi_driver
├── platform       ← 对应 platform_driver
├── pci            ← PCI 总线
├── usb            ← USB 设备
├── mdio_bus       ← PHY 设备
├── amba           ← ARM SoC 特定外设

每个目录底下都包括:

  • /drivers/:驱动注册后的信息(.name)
  • /devices/:设备创建后的路径(device node)

总线是连接设备与驱动的桥梁,它可能是虚拟的(如 platform 总线),也可能是物理的(如 i2c 总线)。平台总线更多是“逻辑建模”的结果,而总线驱动更多依托于硬件结构。


五、匹配机制与设备树支持对比

驱动模型类型匹配字段DTS 中体现设备注册方式
platformcompatible/namecontroller@base(顶层节点)of_platform_populate()
i2c/spi/pcicompatible + regi2c1 → pmic@25i2c_new_device() / 自动扫描
usbUSB ID / device通过 USB 描述符发现热插拔自动创建

特别注意:虽然 platform_driver 是逻辑抽象,但有时它也用于创建“虚拟总线”,如 RPMsg/I2C 桥接场景中,虚拟 I2C 控制器仍通过 platform_driver 注册。


六、总结

我们可以这样更准确地描述 Linux 驱动的分类:

  • 平台驱动模型:用于 SoC 中的控制器类设备(controller)
  • 总线驱动模型:用于挂载在控制器之上的外设(device)

这不是“平台设备 vs 非平台设备”的二元划分,而是“控制器层 vs 外设层”的驱动模型设计逻辑。


✅ 下一篇预告

在《Day 8:下篇》中,我们将以 NXP i.MX8MP 的 I2C1 接口挂载 PCA9450 PMIC 为实例,系统讲解设备树的结构组织、设备与驱动的匹配机制、资源获取、probe 函数流程,并从驱动源码中深度解析总线驱动模型的实战逻辑。敬请期待!


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值