一.Platform初始化
体系启动时初始化时创立了platform_bus设备和platform_bus_type总线:
内核初始化函数kernel_init()中调用了do_basic_setup(),该函数中调用driver_init(),该函数中调用platform_bus_init(),咱们看看platform_bus_init()函数:
int __init platform_bus_init(void)
{
int error;
early_platform_cleanup();
error = device_register(&platform_bus);
if (error)
return error;
error =bus_register(&platform_bus_type);
if (error)
device_unregister(&platform_bus);
return error;
}
device_register(&platform_bus)中的platform_bus如下:
struct device platform_bus = {
.init_name= “platform”,
};
改函数把设备名为platform的设备platform_bus注册到体系中,其他的platform的设备都会以它为parent。它在sysfs中目录下.即/sys/devices/platform。
接着bus_register(&platform_bus_type)注册了platform_bus_type总线,看一下改总线的界说:
struct bus_type platform_bus_type = {
.name= “platform”,
.dev_attrs= platform_dev_attrs,
.match= platform_match,
.uevent= platform_uevent,
.pm= &platform_dev_pm_ops,
};
默许platform_bus_type中没有界说probe函数。
咱们剖析一下其间platform_match和platform_uevent函数。在剖析设备驱动模型是现已知道总线类型match函数是在设备匹配驱动时调用,uevent函数在发生事情时调用。
platform_match()代码如下:
static int platform_match(struct device *dev, struct device_driver *drv)
{
struct platform_device *pdev = to_platform_device(dev);
struct platform_driver *pdrv = to_platform_driver(drv);
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
return (strcmp(pdev->name, drv->name) == 0);
}
static const struct platform_device_id *platform_match_id(
struct platform_device_id *id,
struct platform_device *pdev)
{
while (id->name[0]) {
if (strcmp(pdev->name, id->name) == 0) {
pdev->id_entry = id;
return id;
}
id++;
}
return NULL;
}
不难看出,假如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)
{
struct platform_device*pdev = to_platform_device(dev);
add_uevent_var(env, “MODALIAS=%s%s”, PLATFORM_MODULE_PREFIX,
(pdev->id_entry) ? pdev->id_entry->name : pdev->name);
return 0;
}
添加了MODALIAS环境变量,咱们回忆一下:platform_bus. parent->kobj->kset->uevent_ops为device_uevent_ops,bus_uevent_ops的界说如下:
static struct kset_uevent_ops device_uevent_ops = {
.filter =dev_uevent_filter,
.name =dev_uevent_name,
.uevent = dev_uevent,
};
当调用device_add()时会调用kobject_uevent(&dev->kobj, KOBJ_ADD)发生一个事情,这个函数中会调用相应的kset_uevent_ops的uevent函数,这儿即为dev_uevent(),咱们看一下这个函数的代码片段:
static int dev_uevent(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env)
{
.
.
.
if (dev->bus && dev->bus->uevent) {
retval = dev->bus->uevent(dev, env);
if (retval)
pr_debug(“device: %s: %s: bus uevent() returned %d”,
dev_name(dev), __func__, retval);
}
.
.
.
}
从这儿看到假如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)
{
struct platform_object *pa;
pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
if (pa) {
strcpy(pa->name, name);
pa->pdev.name = pa->name;
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
}
return pa ? &pa->pdev : NULL;
}
该函数首要为platform设备分配内存空间,这儿的struct platform_object结构是struct platform _device结构的封装,其界说如下:
struct platform_object {
struct platform_device pdev;
char name[1];
};
其间第二个字段name的地址用于寄存第一个字段pdev的name指针上的内容,函数中的代码说明晰这点:
strcpy(pa->name, name);
pa->pdev.name = pa->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)
{
int i, ret = 0;
if (!pdev)
return -EINVAL;
if (!pdev->dev.parent)
pdev->dev.parent = & platform_bus;
pdev->dev.bus = &platform_bus_type;
设置父节点和总线,这儿的platform_bus和platform_bus_type在上面的初始化部分现已剖析。
if (pdev->id != -1)
dev_set_name(&pdev->dev, “%s.%d”, pdev->name,pdev->id);
else
dev_set_name(&pdev->dev, “%s”, pdev->name);
设置pdev->dev内嵌的kobj的name字段,它是pdev->name指向的内容加上id,假如id为-1则疏忽它,关于dev_set_name()函数现已在剖析设备驱动模型时剖析过,这儿不再负担。
for (i = 0; i < pdev->num_resources; i++) {
struct resource *p, *r = &pdev->resource[i];
if (r->name == NULL)
r->name = dev_name(&pdev->dev);
p = r->parent;
if (!p) {
if (resource_type(r) == IORESOURCE_MEM)
p = &iomem_resource;
else if (resource_type(r) == IORESOURCE_IO)
p = &ioport_resource;
}
if (p && insert_resource(p, r)) {
printk(KERN_ERR
“%s: failed to claim resource %d”,
dev_name(&pdev->dev), i);
ret = -EBUSY;
goto failed;
}
}
初始化资源并将资源分配给它,每个资源的它的parent不存在则依据flags域设置parent,flags为IORESOURCE_MEM,则所表明的资源为I/O映射内存,flags为IORESOURCE_IO,则所表明的资源为I/O端口。
pr_debug(“Registering platform device %s. Parent at %s”,
dev_name(&pdev->dev), dev_name(pdev->dev.parent));
ret = device_add(&pdev->dev);
就在这儿把设备注册到总线上,假如你对device_add()函数不熟悉,请参阅本站的设别模型剖析部分内容。
if (ret == 0)
return ret;
failed:
while (–i >= 0) {
struct resource *r = &pdev->resource[i];
unsigned long type = resource_type(r);
if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
release_resource(r);
}
除错吊销的内容。
return ret;
}
platform_device_add()函数剖析完了,咱们看下platform_device_register()函数:
int platform_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
return platform_device_add(pdev);
}
没错它便是初始化pdev->dev后调用platform_device_add()把它注册到platform_bus_type上。
在看看platform_device_register_simple()函数:
struct platform_device *platform_device_register_simple(const char *name,
int id,
struct resource *res,
unsigned int num)
{
struct platform_device *pdev;
int retval;
pdev = platform_device_alloc(name, id);
if (!pdev) {
retval = -ENOMEM;
goto error;
}
if (num) {
retval = platform_device_add_resources(pdev, res, num);
if (retval)
goto error;
}
retval = platform_device_add(pdev);
if (retval)
goto error;
return pdev;
error:
platform_device_put(pdev);
return ERR_PTR(retval);
}
该函数便是调用了platform_device_alloc()和platform_device_add()函数来创立的注册platform device,函数也依据res参数分配资源,看看platform_device_add_resources()函数:
int platform_device_add_resources(struct platform_device *pdev,
struct resource *res, unsigned int num)
{
struct resource *r;
r = kmalloc(sizeof(struct resource) * num, GFP_KERNEL);
if (r) {
memcpy(r, res, sizeof(struct resource) * num);
pdev->resource = r;
pdev-> num_resources = num;
}
return r ? 0 : -ENOMEM;
}
很简单,为资源分配内存空间,并复制参数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)
{
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;
return driver_register(&drv->driver);
}
这儿咱们要先看看struct platform_driver结构:
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;
struct platform_device_id *id_table;
};
上面的函数指定了内嵌的driver的bus字段为platform_bus_type,即为它即将注册到的总线。
然后设定了platform_driver内嵌的driver的probe、remove、shutdown函数。
看下相应的这三个函数:
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);
}
static int platform_drv_remove(struct device *_dev)
{
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
return drv->remove(dev);
}
static void platform_drv_shutdown(struct device *_dev)
{
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
drv->shutdown(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,
int (*probe)(struct platform_device *))
{
int retval, code;
drv->driver.suppress_bind_attrs = true;
drv-> probe = probe;
retval = code = platform_driver_register(drv);
spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
return retval;
}
该函数先设置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)
{
return -ENXIO;
}
正如咱们剖析的相同。
到此,Platform总线剖析完了,后边其他模块的剖析中将会有platform的比如,有了上面的根底,届时咱们就能够轻松的剖析了^_^!
声明:本文内容来自网络转载或用户投稿,文章版权归原作者和原出处所有。文中观点,不代表本站立场。若有侵权请联系本站删除(kf@86ic.com)https://www.86ic.net/qiche/adas/233701.html