platform_driver_probe与platform_driver_register的区别[通俗易懂]

platform_driver_probe与platform_driver_register的区别[通俗易懂]

PlatformDeviceandDrivers
我们可以了解Platformbus上面的驱动模型接口:platform_device,platform_driver。和PCI和USB这些大结构的总线不同,虚拟总线Platformbus使用最小结构来集成SOCprocesser上的各种外设,或者各种“legacy”之间的互联。
Platformdevice
典型的Platformdevi

大家好,又见面了,我是你们的朋友全栈君。

Platform Device and Drivers
从<linux/platform_device.h>我们可以了解Platform bus上面的驱动模型接口:platform_device,platform_driver。和PCI和USB这些大结构的总线不同,虚拟总线Platform bus使用最小结构来集成SOC processer上的各种外设,或者各种“legacy”之间的互联。

Platform device
典型的Platform device是系统中的各种自主设备,包括各种桥接在外围总线上的port-based device和host,以及各种集成在SOC platform上的控制器。他们都有一个特点,那就是CPU BUS可以直接寻址,或者特殊的情况platform_device连接在其他总线上,但是它的寄存器是可以被直接寻址的。
Platform device有一个名字,用来进行driver的绑定;还有诸如中断,地址之类的一些资源列表

struct platform_device {

 const char *name;
 u32  id;
 struct device dev;
 u32  num_resources;
 struct resource *resource;
};

Platform drivers
Platform driver满足标准driver model,对driver的discovery/enumeration是在driver外部进行的,driver提供了probe()和 remove()方法.Platfomr dirvers通过标准模型提供power management和shutdown通知。

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 (*suspend_late)(struct platform_device *, pm_message_t state);
 int (*resume_early)(struct platform_device *);
 int (*resume)(struct platform_device *);
 struct device_driver driver;
};

Probe()函数必须验证指定设备的硬件是否真的存在,probe()可以使用设备的资源,包括时钟,platform_data等,Platform driver可以通过下面的函数完成对驱动的注册:
int platform_driver_register(struct platform_driver *drv);
一般来说设备是不能被热插拔的,所以可以将probe()函数放在init段里面来节省driver运行时候的内存开销:
int platform_driver_probe(struct platform_driver *drv,
     int (*probe)(struct platform_device *))

Device Enumeration
作为一个规则,平台(一般来说是板级)启动代码会注册所有的Platform device:
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
一般来说只会注册那些实际存在的设备,不过也存在特殊的情况,比如kernel可能需要与一个不在板子上的外部网络适配器工作,或者那些不挂在任何总线上的控制器。
一般情况下,固件启动的过程会输出一个描述板子上所有存在设备的表。如果没有这个表,系统启动代码建立正确的设备的唯一方法就是为一个特定的板子编译一个kernel。这种board-specific kernel广泛用在嵌入式和一般系统的开发上。
在大部分情况下,设备的memory和IRQ资源不足够让驱动正常工作。board setup code会用device的platform_data域来为设备提供一些额外的资源。
嵌入式系统上的设备会频繁地使用一个或者多个时钟,这些时钟因为节电的原因只有在真正使用的时候才会被打开,系统在启动过程中会为设备分配时钟,可以通过clk_get(&pdev->dev, clock_name)来获得需要的时钟。

Legacy Drivers : Device Probing
一些driver并不会完全遵守标准driver model,这些driver会去注册自己的platform device,而不是让系统来完成注册。这是不值得推
荐的,主要用来兼容以前的一些旧设备。可以通过下面的API来支持这些legacy driver,一般这些API使用在不支持热插拔的driver上面:
 struct platform_device *platform_device_alloc(
   const char *name, int id);
可以使用platform_device_alloc动态地创建一个设备,一个更好的方法是,通过下面的函数动态创建一个设备,并把这个设备注册到系统中:
 struct platform_device *platform_device_register_simple(
   const char *name, int id,
   struct resource *res, unsigned int nres);

Device Naming and Driver Binding
platform_device.dev.bus_id是一个设备在总线上的名字,它包含两部分:
  * platform_device.name   设备名字,用来进行driver的匹配
  * platform_device.id     设备实例的标号,如果是-1,表示同样名字的设备只有一个
举个简单的例子,name/id是“serial/1”则它的bus_id就是serial.1  如果name/id是“serial/0”则它的bus_id就是serial.0 ,如果它的name/id是“serial/-1”则它的bus_id就是serial。
driver的绑定是通过driver core自动完成的,完成driver和device的匹配后以后会自动执行probe()函数,如果函数执行成功,则driver和device就绑定在一起了,drvier和device匹配的方法有3种:
  * 当一个设备注册的时候,他会在总线上寻找匹配的driver,platform device一般在系统启动很早的时候就注册了
  * 当一个驱动注册[platform_driver_register()]的时候,他会遍历所有总线上的设备来寻找匹配,在启动的过程驱动的注册一般比较晚,或者在模块载入的时候
  * 当一个驱动注册[platform_driver_probe()]的时候, 功能上和使用platform_driver_register()是一样的,唯一的区别是它不能被以后其他的device probe了,也就是说这个driver只能和一个device绑定。

      Platform device 和 Platform driver实际上是cpu总线可以直接寻址的设备和驱动,他们挂载在一个虚拟的总线platform_bus_type上,是一种bus-specific设备和驱动。与其他bus-specific驱动比如pci是一样的。他们都是将device和device_driver加了一个warpper产生,仔细看看platform_device就可以看到它必然包含一个device dev,而platform_driver也一样,它必然包含一个device_driver driver。
      所有的设备通过bus_id挂在总线上,多个device可以共用一个driver,但是一个device不可以对应多个driver。驱动去注册时候会根据设备名寻找设备,没有设备会注册失败,注册的过程会通过probe来进行相应资源的申请,以及硬件的初始化,如果probe执行成功,则device和driver的绑定就成功了。设备注册的时候同样会在总线上寻找相应的驱动,如果找到他也会试图绑定,绑定的过程同样是执行probe。

       把内核相关部分的源码基本过一遍就了解了这种新的驱动管理和注册机制,可以参照我在资源里面传的两个文档~~

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/159082.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • 实现KMO和Bartlett的球形度检验的两种方法[通俗易懂]

    实现KMO和Bartlett的球形度检验的两种方法[通俗易懂]文章目录实现KMO和Bartlett的球形度检验的两种方法SPSS实现KMO和Bartlett的球形度检验第一步:选择“因子分析”第二步:选择变量第三步:选择KMO和巴特利特球形度检验输出结果SAS实现KMO和Bartlett的球形度检验数据集来源参考资料实现KMO和Bartlett的球形度检验的两种方法SPSS实现KMO和Bartlett的球形度检验第一步:选择“因子分析”导入数据…

    2022年6月14日
    104
  • gimp教程:gimp界面介绍「建议收藏」

    gimp教程:gimp界面介绍「建议收藏」GIMP(跨平台图像处理程序)是一个开发源代码的光栅与图像编辑的先进功能,关于GIMP的界面,初学者都了解吗?下面是小编整理的关于gimp教程中gimp界面介绍,快来分享吧!gimp界面介绍:gimp图像窗口Gimp图像窗口是打开图形图像文件时图像显示的窗口,关闭窗口右上角的关闭按钮的话程序也将随之关闭。如下图所示,其窗口中包含下面几个元素:A、居于最上面的标题栏,最左面是Gimp图标(icons),中间是图像名,如果是刚开始打开无图像的话显示”GNUImageManipulatio..

    2022年6月15日
    35
  • pycharm运行报错_pycharm failed to create virtual

    pycharm运行报错_pycharm failed to create virtual   

    2022年8月26日
    8
  • 分布式存储系统考虑因素-分区容错性[通俗易懂]

    分布式存储系统考虑因素-分区容错性[通俗易懂]分布式存储系统中的多台服务器通过网络进行连接。但是我们无法保证网络是一直通畅的,分布式系统需要具有一定的容错性来处理网络故障带来的问题。

    2022年7月25日
    5
  • 【有趣的实验】JAVA 遍历数组的几种方式的耗时对比「建议收藏」

    【有趣的实验】JAVA 遍历数组的几种方式的耗时对比「建议收藏」JAVA遍历数组的几种方式的耗时对比

    2022年9月19日
    2
  • Java基础三:Java 核心技术[通俗易懂]

    Java基础三:Java 核心技术[通俗易懂]目录3.Java核心技术3.1.反射机制3.2.异常3.3.多线程3.4.文件与I\O流3.Java核心技术3.1.反射机制JAVA反射机制是在运行状态中,对于任意一个类,都能够知道这个类的所有属性和方法;对于任意一个对象,都能够调用它的任意一个方法和属性;这种动态获取的信息以及动态调用对象的方法的功能称为java语言的反射机制。3.1.1.静态编译和动态编译静态编译:在编译时确定类型,绑定对象 动态编译:运行时确定类型,绑定对象3

    2022年7月8日
    24

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号