Platform_device和platform_driver

本文详细介绍了Linux平台机制下的Platform_device和platform_driver的概念与使用流程。包括如何定义和注册平台设备,平台驱动的结构和注册过程,以及平台设备与驱动之间的匹配机制。还探讨了资源的使用方式和platform_data的应用场景。

通过Platform机制开发发底层驱动的大致流程为: 定义 platform_device---注册 platform_device ---定义 platform_driver-----注册 platform_driver。 

1. Platform_device 定义于 kernel/include/linux/platform_device.h中,

struct platform_device {

 const char * name;

 u32 id;

 struct device dev;

 u32 num_resources;

 struct resource * resource;

};

定义一个platform_device一般需要初始化两个方面的内容:设备占用的资源resource和设备私有数据dev.platform_data。最重要的是resource


设备占用的资源主要是两个方面:IO内存和irq资源。

Resource定义于kernel/include/linux/ioport.h中,

struct resource {

 const char *name;

 unsigned long start, end;

 unsigned long flags;

 struct resource *parent, *sibling, *child;

};

实际上是对地址范围及其属性的一个描述。最后几个用于树型结构的指针是内核用于管理所有资源的。

而platform_data则是设置给struct device dev;中的platform_data指针(void *)。这个指针内核并不使用,而是驱动自身来定义及使用。

比如说对于DM9000,对应的platform_data定义于include/linux/dm9000.H中。

struct dm9000_plat_data {

unsigned int flags;

 

void (*inblk)(void __iomem *reg, void *data, int len);

void (*outblk)(void __iomem *reg, void *data, int len);

void (*dumpblk)(void __iomem *reg, int len);

};

OK,初始化完资源和platform_data,一个平台设备就定义好了。把这个平台设备变量的地址添加到资源列表中去。比如在2410平台:

在arm/arm/mach-s3c2410/mach-smdk2410.c把设备地址添加到*smdk2410_devices[] __initdata 数组中去。

最后在arch/arm/mach-3sc2410/cpu.c 中初始化函数__init s3c_arch_init(void)会对smdk2410_devices[]每一个设备的指针ptr调用platform_device_register(ptr)。主要是建立device的层次结构(建立sysfs入口),将设备占用的资源添加到内核资源管理。接下来看看platform_driver:

 

2. platform_driver结构定义于include/linux/platform_device.H :
struct platform_driver {

int (*probe)(struct platform_device *);

int (*remove)(struct platform_device *);

void (*shutdown)(struct platform_device *);

int (*suspend)(struct platform_device *, pm_message_t state);

int (*resume)(struct platform_device *);

struct device_driver driver;

};

它内部封装了一个device_driver,更有意思的是其它的全是函数,并且这些函数名与device_driver中提供的一样,只是参数由device * 变成了 platform_device *  。

驱动应该实现platform_driver中的这些操作,而内嵌的device_driver中的对应函数则在注册时被指定为内核指定的操作,这些指定操作只是把调用参数转换成platform_driver和platform_device来调用platform_driver提供的操作而已。 好像有点乱。。不过代码可以解释一切:

平台驱动注册:

int platform_driver_register(struct platform_driver *drv)

{

drv->driver.bus = &platform_bus_type;

if (drv->probe)

drv->driver.probe = platform_drv_probe;

if (drv->remove)

drv->driver.remove = platform_drv_remove;

if (drv->shutdown)

drv->driver.shutdown = platform_drv_shutdown;

if (drv->suspend)

drv->driver.suspend = platform_drv_suspend;

if (drv->resume)

drv->driver.resume = platform_drv_resume;

return driver_register(&drv->driver);

}

OK,如果device_driver的方法没有定义就会变成对应的platform_drv_*方法。

 

来看看其中的一个的实现:比如 platform_drv_probe

static int platform_drv_probe(struct device *_dev)

{

struct platform_driver *drv = to_platform_driver(_dev->driver);

struct platform_device *dev = to_platform_device(_dev);

return drv->probe(dev);

}

事情很清楚,先把设备的device_driver转成platform_driver,同样转换device为platform_device。然后去调用platform_driver提供的函数。类型转换当然是通过container_of()宏实现的。

 

因此,驱动只需要实现platform_driver中的方法。然后注册即可。

 

关于注册,由上面的代码可知,最终也是通过 driver_register(&drv->driver);来做的。

 

3.更深入的小窥一下平台设备与平台驱动的注册:

根据LDD3中指出的设备模型,一个设备和驱动必然属于某一个总线。Platform_device和platform-driver在层次上隶属于叫platform_bus_type的总线类型。OK,平台驱动注册的时候(平台设备必须先于驱动注册)将引用它所属总线的匹配函数去决定总线上每一个设备是否属于自己。然后二者建立联系:设备的驱动指针指向该驱动,驱动的设备列表中加入匹配的设备。

 

当然,这是在设备和驱动这一层面来说的,更深入一层,kobjects和ksets建立层次关系,建立sysfs入口等等。。

 

注意,platform_bus_type的匹配函数只是比较一下driver和device的name是否相同。因此,同一设备的platform_device和platform_driver的name应该设为相同的。见platform_bus_type匹配函数定义:
static int platform_match(struct device * dev, struct device_driver * drv)

{

struct platform_device *pdev = container_of(dev, struct platform_device, dev);

return (strncmp(pdev->name, drv->name, BUS_ID_SIZE) == 0);

}

因此,dm9000的platform_device和platform_driver的name都为"Dm9000"。

 

4.下面一个问题:资源怎么用??Platform_data一般怎么用?

资源描述的是设备占用的IO内存,IO端口,及中断线。

Dm9000驱动中是这样使用的。这符合惯例:

在probe中获取资源,并且申请资源,最后映射到内核空间,把映射结果保存起来。

在net_device中的open函数里,注册中断处理函数。

 

Platform_data的使用极为灵活,首先platform_data结构不同设备之间没有定论,一般可用来保存特定于设备的一些配置,操作等。比如对于DM9000,可以存在按字节,按字访问的不同模式,因此其platform_data定义成这样:

struct dm9000_plat_data {

unsigned int flags;

 

void (*inblk)(void __iomem *reg, void *data, int len);

void (*outblk)(void __iomem *reg, void *data, int len);

void (*dumpblk)(void __iomem *reg, int len);

};

其中flags是8/16位模式的选择标志,下面三个是在该模式下的IO存取函数。 

然后Dm9000驱动只使用了它的flags标志,其余的并不使用。

因为对于网络net_device,有一个叫着private_data的指针,在分配一个net_device的时候可以让内核为其开辟指定大小的内存。这部分内存可以通过net_device访问,而且内容也是驱动开发者自定义的。在DM9000的驱动中,net_devict的private_data使用了一个叫board_info的结构体来包括更多设备相关的信息和操作。

dm9000_plat_data提供的内容也被包括进board_info。因此驱动只使用了初始时设置的flags,除此外dm9000_plat_data中的方法没有使用的必要。

 

从中得到的启示:
Device 包含一个platform_data。

Net_device则包含一个private区域.

这样既实现了设备模型的统一管理,又实现了保持不同设备的信息与方法的灵活性。

<think>嗯,用户这次提出的问题涉及Linux驱动框架中platform_deviceplatform_driver的核心工作机制,看来是在深入理解平台设备驱动模型。用户已经看过我前面对module_platform_driver的解析,现在想进一步厘清设备驱动两个结构体的关系。从用户引用资料来看,他对匹配机制特别关注,尤其是设备树出现后的变化。引用[3][4]明确指向platform_match函数,这个确实是关键。用户可能在实际开发中遇到了驱动匹配失败的问题,或者想设计自定义的设备-驱动绑定逻辑。注意到用户提供的引用片段存在几个技术要点需要串联:1.传统方案中platform_device需要显式注册(引用[1])2.匹配通过platform_bus_type.match函数实现(引用[3])3.设备树替代了platform_device的注册(引用[4])这些正好对应着驱动模型演进的三个阶段:裸设备注册、ACPI时代设备树时代。用户提到的“有些驱动里没有platform_device_register”特别值得展开,这正是设备树带来的变革。需要解释清楚:当采用设备树时,platform_device是由内核根据dtb自动生成的。可以画个对比图更直观:传统方式:驱动代码创建platform_device→注册→匹配→probe设备树方式:DTS→dtc→内核解析生成platform_device→匹配→probe关于匹配优先级(引用[2][3]提到platform_match源码),需要强调四步判断顺序:dt的compatible字符串最优先,然后是ACPIID,再是platformdevicename,最后是drv->id_table。这个顺序解释了为什么设备树现在成为主流方案。用户隐藏的问题可能是:“为什么我的驱动probe函数没执行?”这通常就是匹配环节失败。应该补充说明调试方法,比如检查/sys/bus/platform/devicesdrivers目录,以及如何通过dump_device()查看compatible字符串。</think> 在 Linux 驱动框架中,`platform_device` `platform_driver` 是平台总线模型的核心组件,它们通过以下方式协同工作: --- ### 一、核心概念与区别 | **组件** | **作用** | **生命周期** | **数据来源** | |--------------------|----------------------------------------------|-----------------------|--------------------------| | **`platform_device`** | 描述硬件资源<br>(如寄存器地址、中断号、时钟) | 设备注册时创建<br>系统启动或模块加载时生成 | 传统:代码显式定义<br>设备树:内核解析 DTS 自动生成[^4] | | **`platform_driver`** | 实现驱动逻辑<br>(如 `probe()`、`remove()`) | 驱动模块加载时注册<br>通过 `platform_driver_register()` | 由驱动开发者实现<br>需定义操作函数兼容性标识 | --- ### 二、关联机制:匹配流程 #### 1. **注册与匹配过程** ```mermaid sequenceDiagram 设备注册->>总线: platform_device_register() 或 DTS 解析生成[^1][^4] 驱动注册->>总线: platform_driver_register() 总线-->>匹配函数: 调用 platform_match() alt 匹配成功 总线->>驱动: 执行 probe() 函数 else 匹配失败 总线-->>驱动: 等待下次匹配 end ``` #### 2. **匹配规则**(优先级从高到低)[^3][^4] 1. **设备树兼容性** ```c // 驱动定义兼容标识 static const struct of_device_id my_driver_ids[] = { { .compatible = "vendor,device-123" }, // 与设备树中 compatible 匹配 {} }; ``` 2. **ACPI ID** (嵌入式系统较少用) 3. **平台设备名** ```c // platform_device.name 必须与 platform_driver.driver.name 一致 pdev.name = "my_device"; pdrv.driver.name = "my_device"; ``` 4. **驱动 ID 表** ```c static struct platform_device_id my_id_table[] = { {"device_v1", 0}, // 匹配 platform_device.id_entry {} }; ``` --- ### 三、工作流程对比 #### 1. **传统开发模式**(无设备树) ```c // 1. 显式定义设备资源 struct resource res[] = { [0] = DEFINE_RES_MEM(0x12345678, 0x100), // 寄存器地址 [1] = DEFINE_RES_IRQ(IRQ_NUM), // 中断号 }; // 2. 手动注册设备 struct platform_device pdev = { .name = "my_device", .resource = res, }; platform_device_register(&pdev); // 开发者主动注册[^1] // 3. 驱动通过 name 匹配 struct platform_driver pdrv = { .driver = { .name = "my_device" }, // 名称匹配关键 .probe = my_probe, }; platform_driver_register(&pdrv); ``` #### 2. **设备树模式**(主流) ```c // 设备树片段 (DTS) my_device: my_device@12345678 { compatible = "vendor,device-123"; // ⭐ 匹配标识 ⭐ reg = <0x12345678 0x100>; // 寄存器 interrupts = <0 10 IRQ_TYPE_EDGE_RISING>; // 中断 }; // 驱动仅注册 platform_driver struct platform_driver pdrv = { .driver = { .of_match_table = my_driver_ids, // 设备树兼容性表[^4] }, .probe = my_probe, }; module_platform_driver(pdrv); // 自动注册驱动 ``` - **优势**:硬件改动无需重编译驱动[^4] - **内核行为**: DTS → 内核解析 → 自动生成 `platform_device` → 匹配驱动 → 调用 `probe()` --- ### 四、关键函数交互 | **函数** | 作用对象 | 调用时机 | |------------------------|--------------------|--------------------------| | `platform_device_register()` | `platform_device` | 手动注册设备资源(传统模式) | | `platform_driver_register()` | `platform_driver` | 驱动模块初始化时 | | `platform_match()` (⭐总线内核函数⭐) | 总线仲裁 | 设备/驱动注册时自动触发[^3] | --- ### 五、典型问题解析 **问题:为什么某些驱动没有 `platform_device_register`?** **答案**:设备树系统中,设备由 DTS 描述,内核启动时**自动生成**对应的 `platform_device`[^4],驱动只需通过兼容性标识声明匹配关系即可。 **问题:probe 函数如何获取资源?** ```c static int my_probe(struct platform_device *pdev) { // 1. 设备树方式:通过 compatible 匹配后 struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); void __iomem *base = devm_ioremap_resource(&pdev->dev, mem); // 2. 传统方式:直接访问 pdev->resource // pdev->resource[0].start; // 物理地址 } ``` --- **附录:设备树到驱动的数据流** $$ \text{DTS 文件} \xrightarrow{\text{内核解析}} \text{platform\_device} \underset{\text{platform\_match}}{\overset{\text{匹配}}{\rightleftharpoons}} \text{platform\_driver} \xrightarrow{\text{probe()}} \text{驱动初始化} $$ - 设备树通过 `compatible` 提供**设备唯一标识** - 驱动通过 `of_match_table` **声明能支持的设备**[^4] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值