系统启动时初始化时创建了platform_bus设备和platform_bus_type总线:
内核初始化函数kernel_init()中调用了do_basic_setup() ,该函数中调用driver_init(),该函数中调用platform_bus_init(),我们看看platform_bus_init()函数:
int __init platform_bus_init(void)
{
}
device_register(&platform_bus)中的platform_bus如下:
struct device platform_bus = {
};
改函数把设备名为platform 的设备platform_bus注册到系统中,其他的platform的设备都会以它为parent。它在sysfs中目录下.即 /sys/devices/platform。
接着bus_register(&platform_bus_type)注册了platform_bus_type总线,看一下改总线的定义:
struct bus_type platform_bus_type = {
};
默认platform_bus_type中没有定义probe函数。
我们分析一下其中platform_match和platform_uevent函数。在分析设备驱动模型是已经知道总线类型match函数是在设备匹配驱动时调用,uevent函数在产生事件时调用。
platform_match()代码如下:
static int platform_match(struct device *dev, struct device_driver *drv)
{
}
static const struct platform_device_id *platform_match_id(
{
}
不难看出,如果pdrv的id_table数组中包含了pdev->name,或者drv->name和pdev->name名字相同,都会认为是匹配成功。id_table数组是为了应对那些对应设备和驱动的drv->name和pdev->name名字不同的情况。
再看看platform_uevent()函数:
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
}
添加了MODALIAS环境变量,我们回顾一下:platform_bus. parent->kobj->kset->uevent_ops为device_uevent_ops,bus_uevent_ops的定义如下:
static struct kset_uevent_ops device_uevent_ops = {
};
当调用device_add()时会调用kobject_uevent(&dev->kobj, KOBJ_ADD)产生一个事件,这个函数中会调用相应的kset_uevent_ops的uevent函数,这里即为dev_uevent(),我们看一下这个函数的代码片段:
static int dev_uevent(struct kset *kset, struct kobject *kobj,
{
}
从这里看到如果bus->uevent()函数存在则会调用它。
到这里我们清楚了platform_uevent会在哪里调用了。
二.Platform设备的注册
我们在设备模型的分析中知道了把设备添加到系统要调用device_initialize()和platform_device_add(pdev)函数。
对于platform设备的初始化,内核源码也提供了platform_device_alloc()函数。
对于platform设备的初注册,内核源码提供了platform_device_add()函数,它是进行一系列的操作后调用device_add()将设备注册到相应的总线上,内核代码中platform设备的其他注册函数都是基于这个函数,如platform_device_register()、platform_device_register_simple()、platform_device_register_data()等。
我们对这些函数逐个分析,首先看看初始化函数platform_device_alloc():
struct platform_device * platform_device_alloc(const char *name, int id)
{
}
该函数首先为platform设备分配内存空间,这里的struct platform_object结构是struct platform _device结构的封装,其定义如下:
struct platform_object {
};
其中第二个字段name的地址用于存放第一个字段pdev的name指针上的内容,函数中的代码说明了这点:
接着用输入参数id初始化platform_device的id字段,这个id是在设置代表它的kobject时会用到的,我们将在后面分析到,如果不用它,则设为-1。
接着调用device_initialize()初始化platform_device内嵌的device,并设置其release函数指针。
platform_device_alloc()函数分析完了。
接着我们看看platform_device_add()函数:
int platform_device_add(struct platform_device *pdev)
{
设置父节点和总线,这里的platform_bus和platform_bus_type在上面的初始化部分已经分析。
设置pdev->dev内嵌的kobj的name字段,它是pdev->name指向的内容加上id,如果id为-1则忽略它,关于dev_set_name()函数已经在分析设备驱动模型时分析过,这里不再累赘。
初始化资源并将资源分配给它,每个资源的它的parent不存在则根据flags域设置parent,flags为IORESOURCE_MEM,则所表示的资源为I/O映射内存,flags为IORESOURCE_IO,则所表示的资源为I/O端口。
就在这里把设备注册到总线上,如果你对device_add()函数不熟悉,请参考本站的设别模型分析部分内容。
除错撤销的内容。
}
platform_device_add()函数分析完了,我们看下platform_device_register()函数:
int platform_device_register(struct platform_device *pdev)
{
}
没错它就是初始化pdev->dev后调用platform_device_add()把它注册到platform_bus_type上。
在看看platform_device_register_simple()函数:
struct platform_device *platform_device_register_simple(const char *name,
{
error:
}
该函数就是调用了platform_device_alloc()和platform_device_add()函数来创建的注册platform device,函数也根据res参数分配资源,看看platform_device_add_resources()函数:
int platform_device_add_resources(struct platform_device *pdev,
{
}
很简单,为资源分配内存空间,并拷贝参数res中的内容,链接到device并设置其num_resources。
三.Platform设备的注册
我们在设备驱动模型的分析中已经知道驱动在注册要调用driver_register(),platform driver的注册函数platform_driver_register()同样也是进行其它的一些初始化后调用driver_register()将驱动注册到platform_bus_type总线上,看一下这个函数:
int platform_driver_register(struct platform_driver *drv)
{
}
这里我们要先看看struct platform_driver结构:
struct platform_driver {
};
上面的函数指定了内嵌的driver的bus字段为platform_bus_type,即为它将要注册到的总线。
然后设定了platform_driver内嵌的driver的probe、remove、shutdown函数。
看下相应的这三个函数:
static int platform_drv_probe(struct device *_dev)
{
}
static int platform_drv_remove(struct device *_dev)
{
}
static void platform_drv_shutdown(struct device *_dev)
{
}
从这三个函数的代码可以看到,又找到了相应的platform_driver和platform_device,然后调用platform_driver的probe、remove、shutdown函数。这是一种高明的做法:在不针对某个驱动具体的probe、remove、shutdown指向的函数,而通过上三个过度函数来找到platform_driver,然后调用probe、remove、shutdown接口。
如果设备和驱动都注册了,就可以通过bus ->match、 bus->probe或driver->probe进行设备驱动匹配了,这部分内容将留到具体的设备中再做分析。
在2.6.32.3版本的代码中,还针对某些不需要产生hotplug事件的设备提供设备驱动的匹配函数platform_driver_probe(),调用这个函数前首先要注册设备,看一下这个函数:
int __init_or_module platform_driver_probe(struct platform_driver *drv,
{
}
该函数先设置drv的probe为输入函数,然后将drv注册到总线,这个过程回去匹配设备,这时会找到调用这个函数前注册的设备,然后将其挂钩,接着设置drv->probe为NULL,设置drv->driver.probe 为platform_drv_probe_fail,这样后面如果产生匹配事件都会是匹配失败,也即platform_drv_probe_fail()匹配不成功,其代码如下:
static int platform_drv_probe_fail(struct device *_dev)
{
}
正如我们分析的一样。
上一篇:计算机总线讲解
下一篇:SPI总线简介及原理