前面几章我们分析了LINUX设备驱动模型&＃xff0c;说明了总线注册、设备注册、驱动注册以及它们之间是如何绑定的。借助之前的分析基础&＃xff0c;本文以platform模块为例&＃xff0c;介绍系统中如何创建总线、设备以及驱动的实例。

platform总线是一个虚拟的总线&＃xff0c;该模块的出现实现了资源与驱动的隔离。一般没有驱动程序

仅实现platform-driver&＃xff0c;该模型一般用于各具体的设备驱动模块&＃xff08;如i2c、spi、pcie、gpio、watchdog等&＃xff09;&＃xff0c;这样即可通过platform-device将各具体设备驱动相关的资源信息&＃xff08;如中断号、寄存器地址等&＃xff09;从驱动中抽离出来&＃xff0c;使得驱动模块更通用。

如我们实现一个I/O引脚模拟jtag引脚的字符驱动程序&＃xff0c;在不使用platform模块时&＃xff0c;那我们在

该字符驱动文件中定义使用的具体I/O值&＃xff0c;这就使得该字符设备驱动不通用了&＃xff08;若下一个硬件版本修改了I/O引脚值&＃xff0c;是否需要修改该字符设备驱动呢&＃xff1f;&＃xff09;。若借助platform模块实现该字符设备驱动&＃xff0c;则可以达到字符设备驱动的通用性&＃xff0c;我们将引脚信息通过platform-device传递&＃xff0c;而在platform-driver的probe接口中&＃xff0c;我们进行字符设备驱动的创建&＃xff0c;并传递I/O引脚的信息。通过platform-driver、cdev-add这两个模块&＃xff0c;就使我们的I/O模拟jtag引脚的字符设备驱动更加通用&＃xff0c;不需要依赖硬件开发板的改变而更新驱动。

platform模块与linux设备树的结合&＃xff0c;真的是linux内核的一大特点&＃xff0c;将之前linux板级文件更改

需要重新编译内核的步骤彻底摆除了。在linux系统内核中&＃xff0c;只需要在内核启动时解析设备树文件&＃xff0c;并调用platform的接口&＃xff0c;为设备树中的节点创建platform设备&＃xff0c;然后在具体的platform设备驱动加载时&＃xff0c;解析注册的platform-device设备的资源信息&＃xff0c;获取这些资源信息&＃xff0c;并进行具体模块驱动的注册&＃xff08;misc_register、i2c_add_numbered_adapter、input_register_device、pci_register_driver等&＃xff09;。

本次platform模块&＃xff0c;我们依旧从如下几个方面分析&＃xff1a;

1. 相关结构体分析及关联图说明
2. Platform bus定义
3. platform模块初始化
4. platform总线相关接口分析
5. platform设备相关接口分析
6. platform驱动相关接口分析

相关结构体分析及关联图说明

        既然platform模块的实现时继承自device-bus-driver模型&＃xff0c;因此其device、driver结构体定义应该也是包含device-driver、device类型的成员变量&＃xff0c;从而实现继承功能。此处我们从platform模块的功能入手&＃xff0c;来说明platform相关结构体。

针对platform模块而言相关的结构体包括struct platform_driver、struct platform_device、struct platform_device_info 、struct platform_device_id 、struct resource等。

struct platform_driver

该结构体可以理解为struct device_driver的子类&＃xff0c;该结构体在包含device_driver类型变量的

基础上&＃xff0c;还定义了probe、remove、suspend等函数指针&＃xff08;有一点点类似于面向对象的多态&＃xff0c;通过调用device_driver->probe&＃xff0c;最终调用platform_driver->probe&＃xff09;&＃xff0c;而id_table主要用于说明该驱动可匹配的设备名称&＃xff0c;用于platform的device-driver匹配时使用。

该结构体的定义如下&＃xff0c;

struct platform_driver {/*驱动的probe、remove等&＃xff0c;在在device-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 *);/*可以将device_driver理解为基类&＃xff0c;则platform_driver为子类*/struct device_driver driver;/*标识该驱动所识别的device信息&＃xff08;主要是根据name值进行platform device-driver的绑定&＃xff09;*/const struct platform_device_id *id_table;};


   相对来说就是包裹了device_driver类型的变量&＃xff0c;同时增加该driver支持设备的id_table&＃xff0c;以及针对device_driver的probe、remove、suspend、resume接口的自定义内容&＃xff08;类似于面向对象中子类重写父类的方法&＃xff09;。

struct platform_device

该结构体用于表征一个platform device&＃xff0c;其也内嵌了struct device类型的变量&＃xff0c;以便继承

device类型的特性&＃xff0c;同时完成与driver、bus的关联。该结构体还包含了资源类型的变量&＃xff0c;以便传递给platform驱动&＃xff0c;由驱动进行申请资源&＃xff0c;同时也实现了资源与驱动的隔离。

struct platform_device {const char *name;int id;bool id_auto;struct device dev;u32 num_resources;/*该platform设备对应的资源&＃xff0c;通过该变量实现设备资源与设备驱动的抽离&＃xff0c;使驱动更加通用*/struct resource *resource;/*该变量为对应driver中的id_table。针对不支持设备树的linux&＃xff0c;则通过id_table中的name并与platform->name进行匹配&＃xff1b;针对支持设备树的linux&＃xff0c;则会根据device->of_node与device_driver->of_match_table中的参数匹配。设备驱动模型通过device_driver、device->of_node实现了对设备树的支持。*/const struct platform_device_id *id_entry;/* MFD cell pointer */struct mfd_cell *mfd_cell;/* arch specific additions */struct pdev_archdata archdata;
};

struct resource结构体

在上面说明中&＃xff0c;我们知道platform模块很好的将资源与驱动抽离&＃xff0c;因此必然存在表示资源的结

构体变量&＃xff0c;且与platform_device关联。该结构体的定义如下&＃xff0c;其可以表示寄存器地址及区间&＃xff0c;也可以表示中断信息等。

/*资源信息&＃xff0c;包含寄存器地址空间、中断等*/
struct resource {resource_size_t start;resource_size_t end;const char *name;unsigned long flags;struct resource *parent, *sibling, *child;
};


struct platform_device_info

该结构体用于描述一个platform device的信息&＃xff0c;根据该结构体变量传递的信息&＃xff0c;可以创建一个platform device。该结构体主要和platform device的创建有关&＃xff0c;和platform device-bus-driver的关联倒是不大。

/*该结构体主要用于描述待一个platform device的信息&＃xff0c;包括该platform-device对应的parent-device
该platform-device的名称、该platform-device所包含的资源、dma信息等&＃xff0c;根据该
信息可以创建一个platform device*/
struct platform_device_info {struct device *parent;struct acpi_dev_node acpi_node;const char *name;int id;const struct resource *res;unsigned int num_res;const void *data;size_t size_data;u64 dma_mask;
};

platform bus-device-driver的关联

    以上即是platform模块相关的结构体&＃xff0c;主要说明了一个platfom 模块如何使用linux设备驱动模型中的结构体及函数指针实现具体的总线模块&＃xff08;可以理解为面向对象中的多态&＃xff09;。下面我们基于之前对linux设备驱动模型的学习基础&＃xff0c;将platform device、driver与设备驱动模块的关联描述一下&＃xff08;我们之前在设备驱动模型中已经介绍过&＃xff0c;此处还是给出它们三者的关联图&＃xff0c;希望对设备驱动模型不熟悉的人也可以快速理解&＃xff09;。

如下图所示&＃xff0c;platform-device、platform-driver借助其中的device类型以及device_driver

类型的成员变量&＃xff0c;实现bus_type、device、device_driver等设备模型关联图的建立&＃xff0c;从而可以借助设备驱动模型中定义的接口&＃xff0c;实现设备驱动的绑定等功能。下图在细节上可能需要斟酌&＃xff0c;但对于描述platform-device、platform-driver、bus_type、device、device_driver、kobject等的关联来说&＃xff0c;也已经足够了&＃xff0c;基本上理解了下图间结构体的关联&＃xff0c;基本上也可以理解platform 总线注册与否、driver注册与注销、device的注册与注销的实现了。&＃xff08;关于设备驱动模型、sysfs文件系统等内容的实现&＃xff0c;我已经在之前的文档中分析过&＃xff0c;需要了解的童鞋可查看我之前的分析文档&＃xff09;。

platform总线的定义

platform总线的定义如下&＃xff0c;platform总线没有定义probe接口&＃xff0c;因此在进行device-driver的绑定时&＃xff0c;将直接调用device类型变量的probe接口进行探测操作。

其中也定义了platform设备的默认device属性&＃xff0c;针对platform类型的设备&＃xff0c;均会定义一个默

认属性&＃xff0c;即在每一个platform设备对应的目录下&＃xff0c;均会创建一个名为“modalias”的文件。

而match接口platform_match&＃xff0c;则定义了platform模块device-driver匹配的通用接口&＃xff0c;该接

口中包含了针对支持设备树以及不支持设备树的匹配方式&＃xff1a;

若不支持设备树&＃xff0c;则根据id_table中的变量进行device-driver的匹配&＃xff1b;

若支持设备树&＃xff0c;则借助device->of_node与device_driver->of_match_table中的参数进行device-driver的匹配验证。

而uevent接口则主要将该platform总线的uevent事件&＃xff0c;当该总线上增加设备或驱动时&＃xff0c;会调用该接口增加该platform相关的event变量&＃xff0c;并发送给应用层。

总线名称为platform&＃xff0c;默认的设备属性为platform_dev_attrs*/
struct bus_type platform_bus_type &＃61; {.name &＃61; "platform",.dev_attrs &＃61; platform_dev_attrs,.match &＃61; platform_match,.uevent &＃61; platform_uevent,.pm &＃61; &platform_dev_pm_ops,
};
static struct device_attribute platform_dev_attrs[] &＃61; {__ATTR_RO(modalias),__ATTR_NULL,
};


Platform模块的初始化

针对platform模型的初始化接口platform_bus_init&＃xff0c;包括了platform总线的注册、platforom总线对应设备的注册等。其函数实现如下&＃xff1a;

int __init platform_bus_init(void)
{int error;early_platform_cleanup();error &＃61; device_register(&platform_bus);if (error)return error;error &＃61; bus_register(&platform_bus_type);if (error)device_unregister(&platform_bus);return error;
}


该函数其实就是调用device_register、bus_register实现了platform总线注册以及总线对应设备的注册&＃xff08;关于这几个接口在之前的设备驱动模型分析中已经说明过&＃xff0c;此处不赘述&＃xff09;。

 

 

platform设备注册

platform设备的注册&＃xff0c;主要也就是调用device_register接口&＃xff0c;将platform device注册到platform总线上&＃xff0c;并试图完成platform device-driver的绑定操作。

针对platform设备注册的接口包括platform_driver_register、platform_device_add等&＃xff0c;其中platform_register就是调用device_initialize、platform_device_add实现对device的初始化及注册操作&＃xff0c;而针对platform_device_add接口&＃xff0c;其实现流程如下&＃xff0c;在完成针对platform相关的设备名称、依附总线、所包含资源的链接外&＃xff0c;即调用device_add实现设备的注册操作。

针对device_add接口&＃xff0c;我们在之前已经分析过&＃xff0c;主要完成device-bus的绑定&＃xff08;包括对应kobject之间的关联、属性创建、uevent变量的添加、class模块的关联等等&＃xff09;&＃xff0c;此处我们仅细说下device-driver的绑定以及设备探测相关的内容&＃xff0c;如下图所示&＃xff0c;通过一系统的函数调用&＃xff0c;最终通过调用接口driver_probe_device&＃xff0c;实现设备的探测&＃xff0c;通过调用device_driver->probe完成对设备的探测操作&＃xff08;此处没有画出是调用bus->probe&＃xff0c;因为platform总线没有实现probe接口&＃xff09;&＃xff0c;而driver->probe最终是调用platform_driver->probe&＃xff0c;实现对platform设备的探测操作。

 

Platform 驱动注册

platform驱动的注册接口为platform_driver_register&＃xff0c;该接口的定义如下&＃xff0c;主要是设置该驱动所依附的总线为platform_bus_type&＃xff0c;同时设置该platform的probe、remove、shutdown接口&＃xff08;若platform driver设置了这几个函数指针&＃xff0c;则通过将platform_driver->driver对应的接口为platform_drv_probe、platform_drv_remove、platform_drv_shutdown等&＃xff0c;而这几个接口最终还是会调用platform_driver中的具体接口&＃xff0c;如上图所示&＃xff09;。

然后调用driver_register进行驱动的注册&＃xff0c;所谓驱动注册主要也就是完成driver-bus的绑定&＃xff08;包括kobject相关的绑定、属性文件的创建、uevent设置等等&＃xff09;&＃xff0c;并调用bus_add_driver&＃xff0c;实现driver-device的绑定&＃xff0c;如上图所示&＃xff0c;针对platform_driver->driver->probe指针&＃xff0c;要么为空&＃xff0c;要么为platform_drv_probe&＃xff0c;而在platform_drv_probe接口中&＃xff0c;则调用platform_driver->probe&＃xff0c;调用关系如上图中虚线箭头所指。

int platform_driver_register(struct platform_driver *drv)
{drv->driver.bus &＃61; &platform_bus_type;if (drv->probe)drv->driver.probe &＃61; platform_drv_probe;if (drv->remove)drv->driver.remove &＃61; platform_drv_remove;if (drv->shutdown)drv->driver.shutdown &＃61; platform_drv_shutdown;return driver_register(&drv->driver);
}


 

Platform device、driver的注销

关于它们注销的接口&＃xff0c;分别为platform_driver_unregister、platform_device_unregister&＃xff0c;与上述的注册接口实现的功能刚好相反&＃xff0c;也就是调用device_del、driver_unregister实现注销操作&＃xff0c;此处不再分析device_del、driver_unregister。此处主要说明一下注销时detach的过程。

不管是设备的注销还是驱动的注销&＃xff0c;通过一系统的系统调用&＃xff0c;最终会调用drv->remove接口&＃xff0c;实现remove操作&＃xff0c;而remove接口即为platform_drv_remove&＃xff0c;该接口会调用具体platform_driver->remove接口进行实现的remove操作&＃xff0c;调用关系如下图虚线箭头所指。

以上即是detach的过程。

 

 

 

本文主要介绍了platform的概念以及platform总线存在的意义、platform模块相关的结构体、platform总线的注册、platform设备的注册与注销、platform驱动的注册与注销等。platform总线的出现&＃xff0c;有效的将driver与设备资源进行隔开&＃xff0c;同时也为设备树在内核的推广提供了一个较好的方式。