设备总线驱动模型:http://blog.csdn.NET/lizuobin2/article/details/51570196
本文主要参考:http://www.wowotech.net/device_model/platform_device.html
platform平台设备驱动是基于设备总线驱动模型的,它只不过是将 device 进一步封装成为 platform_device,将 device_driver 进一步封装成为 platform_device_driver,前面已经分析过设备总线驱动模型,关于device 与 device_driver 的注册过程以及它们在sysfs文件系统中的层次关系就不在分析,本文重点分析platform平台设备驱动与设备总线驱动模型相比较新增添的那些东西。
在Linux设备模型的抽象中,存在着一类称作“Platform Device”的设备,内核是这样描述它们的(Documentation/driver-model/platform.txt):
Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable.
概括来说,Platform设备包括:基于端口的设备(已不推荐使用,保留下来只为兼容旧设备,legacy);连接物理总线的桥设备;集成在SOC平台上面的控制器;连接在其它bus上的设备(很少见)。等等。
这些设备有一个基本的特征:可以通过CPU bus直接寻址(例如在嵌入式系统常见的“寄存器”)。因此,由于这个共性,内核在设备模型的基础上(device和device_driver),对这些设备进行了更进一步的封装,抽象出paltform bus、platform device和platform driver,以便驱动开发人员可以方便的开发这类设备的驱动。
可以说,paltform设备对linux驱动工程师是非常重要的,因为我们编写的大多数设备驱动,都是为了驱动plaftom设备。
platform_bus_type
我们知道,在设备总线驱动模型的中,BUS像一个月老一样,通过它的match函数,将注册到bus中的device与driver进行配对,那么每一个不同的bus 都有自己的match函数,我们来看看platform_bus_type.
如果platform_device_driver中定义了id_table,则调用 platform_match_id 进行匹配
举个例子:
显然,platform_match_id 的作用就是遍历整个 Id_table 数组,寻找是否有与 platform_device->name 同名的,如果有,则返回这个 Platform_device_id ,使用Id_table 打破了原本设备总线驱动模型,一个 device 只能用与一个 device_driver 配对的局限性。现在一个platform_device_driver 可以与多个platform_device配对。
如果没有,则只是根据 platform_device_driver->name 与 platform_device->name 进行比较,这也就是老师为啥在写平台设备驱动程序的时候经常说,“将驱动注册到内核中去,如果有同名设备,则调用driver->probe函数....”。
pletform_device 中的 id 的作用:
if (pdev->id != -1) /* 如果不是-1 对name编号 */
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
else /* -1时直接是名字 */
dev_set_name(&pdev->dev, pdev->name);
从device封装而来的platform_device
name,设备的名称,该名称在设备注册时,会拷贝到dev.init_name中。
dev,真正的设备,通过 container_of ,就能找到整个platform_device ,访问其它成员,如后面要提到的 resource
num_resources、resource,该设备的资源描述,由struct resource(include/linux/ioport.h)结构抽象。
在Linux中, 系统资源包括I/O、Memory、Register、IRQ、DMA、Bus等多种类型。这些资源大多具有独占性,不允许多个设备同时使用,因此Linux内核提供了一些API,用于分配、管理这些资源。
当某个设备需要使用某些资源时,只需利用struct resource组织这些资源(如名称、类型、起始、结束地址等),并保存在该设备的resource指针中即可。然后在设备probe时,设备需求会调用资源管理接口,分配、使用这些资源。而内核的资源管理逻辑,可以判断这些资源是否已被使用、是否可被使用等等。
struct platform_driver结构和struct device_driver非常类似,上边的platform_drv_probe、platform_drv_remove、platform_drv_shutdown,只不过稍作转换调用platform_driver中的probe、remove、shutdown函数,举个例子稍微看一下
arch_setup_pdev_archdata,设置platform_device变量中的archdata指针。
platform_get_resource、platform_get_irq、platform_get_resource_byname、platform_get_irq_byname,通过这些接口,可以获取platform_device变量中的resource信息,以及直接获取IRQ的number等等。
platform_device_register_full、platform_device_register_resndata、platform_device_register_simple、platform_device_register_data,其它形式的设备注册。调用者只需要提供一些必要的信息,如name、ID、resource等,Platform模块就会自动分配一个struct platform_device变量,填充内容后,注册到内核中。
platform_device_alloc,以name和id为参数,动态分配一个struct platform_device变量。
platform_device_add_resources,向platform device中增加资源描述。
platform_device_add_data,向platform device中添加自定义的数据(保存在pdev->dev.platform_data指针中)。
platform_device_add、platform_device_del、platform_device_put,其它操作接口。
Platform Driver提供的API
platform_driver_registe、platform_driver_unregister,platform driver的注册、注销接口。
platform_driver_probe,主动执行probe动作。
platform_set_drvdata、platform_get_drvdata,设置或者获取driver保存在device变量中的私有数据。
懒人API
只要提供一个platform_driver(要把driver的probe接口显式的传入),并告知该设备占用的资源信息,platform模块就会帮忙分配资源,并执行probe操作。对于那些不需要热拔插的设备来说,这种方式是最省事的了。
简单一例:
开发板:Mini2440
内核版本:2.6.32.2
设备总线驱动模型:http://blog.csdn.NET/lizuobin2/article/details/51570196
本文主要参考:http://www.wowotech.net/device_model/platform_device.html
platform平台设备驱动是基于设备总线驱动模型的,它只不过是将 device 进一步封装成为 platform_device,将 device_driver 进一步封装成为 platform_device_driver,前面已经分析过设备总线驱动模型,关于device 与 device_driver 的注册过程以及它们在sysfs文件系统中的层次关系就不在分析,本文重点分析platform平台设备驱动与设备总线驱动模型相比较新增添的那些东西。
在Linux设备模型的抽象中,存在着一类称作“Platform Device”的设备,内核是这样描述它们的(Documentation/driver-model/platform.txt):
Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable.
概括来说,Platform设备包括:基于端口的设备(已不推荐使用,保留下来只为兼容旧设备,legacy);连接物理总线的桥设备;集成在SOC平台上面的控制器;连接在其它bus上的设备(很少见)。等等。
这些设备有一个基本的特征:可以通过CPU bus直接寻址(例如在嵌入式系统常见的“寄存器”)。因此,由于这个共性,内核在设备模型的基础上(device和device_driver),对这些设备进行了更进一步的封装,抽象出paltform bus、platform device和platform driver,以便驱动开发人员可以方便的开发这类设备的驱动。
可以说,paltform设备对linux驱动工程师是非常重要的,因为我们编写的大多数设备驱动,都是为了驱动plaftom设备。
platform_bus_type
我们知道,在设备总线驱动模型的中,BUS像一个月老一样,通过它的match函数,将注册到bus中的device与driver进行配对,那么每一个不同的bus 都有自己的match函数,我们来看看platform_bus_type.
如果platform_device_driver中定义了id_table,则调用 platform_match_id 进行匹配
举个例子:
显然,platform_match_id 的作用就是遍历整个 Id_table 数组,寻找是否有与 platform_device->name 同名的,如果有,则返回这个 Platform_device_id ,使用Id_table 打破了原本设备总线驱动模型,一个 device 只能用与一个 device_driver 配对的局限性。现在一个platform_device_driver 可以与多个platform_device配对。
如果没有,则只是根据 platform_device_driver->name 与 platform_device->name 进行比较,这也就是老师为啥在写平台设备驱动程序的时候经常说,“将驱动注册到内核中去,如果有同名设备,则调用driver->probe函数....”。
pletform_device 中的 id 的作用:
if (pdev->id != -1) /* 如果不是-1 对name编号 */
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
else /* -1时直接是名字 */
dev_set_name(&pdev->dev, pdev->name);
从device封装而来的platform_device
name,设备的名称,该名称在设备注册时,会拷贝到dev.init_name中。
dev,真正的设备,通过 container_of ,就能找到整个platform_device ,访问其它成员,如后面要提到的 resource
num_resources、resource,该设备的资源描述,由struct resource(include/linux/ioport.h)结构抽象。
在Linux中, 系统资源包括I/O、Memory、Register、IRQ、DMA、Bus等多种类型。这些资源大多具有独占性,不允许多个设备同时使用,因此Linux内核提供了一些API,用于分配、管理这些资源。
当某个设备需要使用某些资源时,只需利用struct resource组织这些资源(如名称、类型、起始、结束地址等),并保存在该设备的resource指针中即可。然后在设备probe时,设备需求会调用资源管理接口,分配、使用这些资源。而内核的资源管理逻辑,可以判断这些资源是否已被使用、是否可被使用等等。
struct platform_driver结构和struct device_driver非常类似,上边的platform_drv_probe、platform_drv_remove、platform_drv_shutdown,只不过稍作转换调用platform_driver中的probe、remove、shutdown函数,举个例子稍微看一下
arch_setup_pdev_archdata,设置platform_device变量中的archdata指针。
platform_get_resource、platform_get_irq、platform_get_resource_byname、platform_get_irq_byname,通过这些接口,可以获取platform_device变量中的resource信息,以及直接获取IRQ的number等等。
platform_device_register_full、platform_device_register_resndata、platform_device_register_simple、platform_device_register_data,其它形式的设备注册。调用者只需要提供一些必要的信息,如name、ID、resource等,Platform模块就会自动分配一个struct platform_device变量,填充内容后,注册到内核中。
platform_device_alloc,以name和id为参数,动态分配一个struct platform_device变量。
platform_device_add_resources,向platform device中增加资源描述。
platform_device_add_data,向platform device中添加自定义的数据(保存在pdev->dev.platform_data指针中)。
platform_device_add、platform_device_del、platform_device_put,其它操作接口。
Platform Driver提供的API
platform_driver_registe、platform_driver_unregister,platform driver的注册、注销接口。
platform_driver_probe,主动执行probe动作。
platform_set_drvdata、platform_get_drvdata,设置或者获取driver保存在device变量中的私有数据。
懒人API
只要提供一个platform_driver(要把driver的probe接口显式的传入),并告知该设备占用的资源信息,platform模块就会帮忙分配资源,并执行probe操作。对于那些不需要热拔插的设备来说,这种方式是最省事的了。
简单一例:
开发板:Mini2440
内核版本:2.6.32.2