注:基於Linux-2.6.38
上一篇說了平台設備是怎么注冊進內核的,這一篇要說平台驅動(platform driver)的注冊過程,看看當平台驅動注冊進內核時是怎么與平台設備“聯系”起來的。知道這些之后,以后想移植到新的內核或者添加其他平台設備(如SPI,IIC設備)或者編寫平台設備驅動(如SPI,IIC驅動)就知道該怎么下手了。
這里以s3c處理器的framebuffer驅動為例進行說明(其他的平台驅動原理一樣)。找到/drivers/video/samsung/s3cfb.c,首先看模塊的初始化函數:
1 int __devinit s3cfb_init(void) 2 { 3 return platform_driver_register(&s3cfb_driver); 4 }
第3行調用platform_driver_register(),參數s3cfb_driver的類型為struct platform_driver,看看它的定義:
1 static struct platform_driver s3cfb_driver = { 2 .probe = s3cfb_probe, 3 .remove = s3cfb_remove, 4 .suspend = s3cfb_suspend, 5 .resume = s3cfb_resume, 6 .driver = { 7 .name = "s3c-fb", 8 .owner = THIS_MODULE, 9 }, 10 };
第2~5行給一些函數指針賦值,記住第7行這個name成員的值,后面會再提到;下面看platform_driver_register()在drivers/base/platform.c里的定義:
1 int platform_driver_register(struct platform_driver *drv) 2 { 3 drv->driver.bus = &platform_bus_type; 4 if (drv->probe) 5 drv->driver.probe = platform_drv_probe; 6 if (drv->remove) 7 drv->driver.remove = platform_drv_remove; 8 if (drv->shutdown) 9 drv->driver.shutdown = platform_drv_shutdown; 10 11 return driver_register(&drv->driver); 12 }
第3行,設置當前驅動所在的總線,從這里可以看出,平台設備和平台驅動處在同一條總線上;第4~9行,也是一些函數指針賦值操作;關鍵看第11行調用的在drivers/base/driver.c里定義的driver_register():
1 int driver_register(struct device_driver *drv) 2 { 3 int ret; 4 struct device_driver *other; 5 6 BUG_ON(!drv->bus->p); 7 8 if ((drv->bus->probe && drv->probe) || 9 (drv->bus->remove && drv->remove) || 10 (drv->bus->shutdown && drv->shutdown)) 11 printk(KERN_WARNING "Driver '%s' needs updating - please use " 12 "bus_type methods\n", drv->name); 13 14 other = driver_find(drv->name, drv->bus); 15 if (other) { 16 put_driver(other); 17 printk(KERN_ERR "Error: Driver '%s' is already registered, " 18 "aborting...\n", drv->name); 19 return -EBUSY; 20 } 21 22 ret = bus_add_driver(drv); 23 if (ret) 24 return ret; 25 ret = driver_add_groups(drv, drv->groups); 26 if (ret) 27 bus_remove_driver(drv); 28 return ret; 29 }
看第14行的driver_find():
1 struct device_driver *driver_find(const char *name, struct bus_type *bus) 2 { 3 struct kobject *k = kset_find_obj(bus->p->drivers_kset, name); 4 struct driver_private *priv; 5 6 if (k) { 7 priv = to_driver(k); 8 return priv->driver; 9 } 10 return NULL; 11 }
通過函數的2個參數就可以知道,意思就是在bus總線上通過name找到它所對應的驅動。其實這里是不會找得到的,如果能找到就說明當前驅動之前已經注冊過,就會返回出錯信息。
回到driver_register()第22行的bus_add_driver(),這個函數有點長,只給出關鍵部分:
1 int bus_add_driver(struct device_driver *drv) 2 { 3 ........................................... 4 if (drv->bus->p->drivers_autoprobe) { 5 error = driver_attach(drv); 6 if (error) 7 goto out_unregister; 8 } 9 .......................................
第4行的if條件一般會成立,因此看第5行的driver_attach():
1 int driver_attach(struct device_driver *drv) 2 { 3 return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); 4 }
遍歷總線上每一個已經注冊了的設備,每找到一個就調用__driver_attach()來判斷是否與當前驅動匹配(怎么樣才算匹配?答案即將揭曉),因此有必要看看__driver_attach()的定義:
1 static int __driver_attach(struct device *dev, void *data) 2 { 3 struct device_driver *drv = data; 4 5 /* 6 * Lock device and try to bind to it. We drop the error 7 * here and always return 0, because we need to keep trying 8 * to bind to devices and some drivers will return an error 9 * simply if it didn't support the device. 10 * 11 * driver_probe_device() will spit a warning if there 12 * is an error. 13 */ 14 15 if (!driver_match_device(drv, dev)) 16 return 0; 17 18 if (dev->parent) /* Needed for USB */ 19 device_lock(dev->parent); 20 device_lock(dev); 21 if (!dev->driver) 22 driver_probe_device(drv, dev); 23 device_unlock(dev); 24 if (dev->parent) 25 device_unlock(dev->parent); 26 27 return 0; 28 }
如果第15行的driver_match_device()返回0的話后面的都不用執行了,看看它的定義:
1 static inline int driver_match_device(struct device_driver *drv, 2 struct device *dev) 3 { 4 return drv->bus->match ? drv->bus->match(dev, drv) : 1; 5 }
第4行,如果drv->bus->match這個函數有定義,就調用drv->bus->match函數,否則返回1。在這里可以告訴你,drv->bus->match是有定義的,不信?那去看看。
1 struct bus_type platform_bus_type = { 2 .name = "platform", 3 .dev_attrs = platform_dev_attrs, 4 .match = platform_match, 5 .uevent = platform_uevent, 6 .pm = &platform_dev_pm_ops, 7 };
是吧,再去看看match函數:
1 static int platform_match(struct device *dev, struct device_driver *drv) 2 { 3 struct platform_device *pdev = to_platform_device(dev); 4 struct platform_driver *pdrv = to_platform_driver(drv); 5 6 /* Attempt an OF style match first */ 7 if (of_driver_match_device(dev, drv)) 8 return 1; 9 10 /* Then try to match against the id table */ 11 if (pdrv->id_table) 12 return platform_match_id(pdrv->id_table, pdev) != NULL; 13 14 /* fall-back to driver name match */ 15 // 16 return (strcmp(pdev->name, drv->name) == 0); 17 }
第8行和第12行,這兩條返回語句對於當前來說都不會被執行,因此重點在第16行,drv->name的值在本篇的最前面可以看到是"s3c-fb",接下來看pdev->name的值:
1 struct platform_device s3c_device_fb = { 2 .name = "s3c-fb", 3 .id = -1, 4 .num_resources = ARRAY_SIZE(s3c_fb_resource), 5 .resource = s3c_fb_resource, 6 .dev.dma_mask = &s3c_device_fb.dev.coherent_dma_mask, 7 .dev.coherent_dma_mask = 0xffffffffUL, 8 };
第2行,看到了吧,也是"s3c-fb",事實上在這里看來這兩個值一定要相同,驅動靠它來找到對應的設備。
好了,回到__driver_attach()第18行以后的內容,其中第22行的driver_probe_device()會被執行,看它的定義:
1 int driver_probe_device(struct device_driver *drv, struct device *dev) 2 { 3 int ret = 0; 4 5 if (!device_is_registered(dev)) 6 return -ENODEV; 7 8 pr_debug("bus: '%s': %s: matched device %s with driver %s\n", 9 drv->bus->name, __func__, dev_name(dev), drv->name); 10 11 pm_runtime_get_noresume(dev); 12 pm_runtime_barrier(dev); 13 ret = really_probe(dev, drv); 14 pm_runtime_put_sync(dev); 15 16 return ret; 17 }
關鍵在第13行,really_probe()實現了真正的探測:
1 static int really_probe(struct device *dev, struct device_driver *drv) 2 { 3 int ret = 0; 4 5 atomic_inc(&probe_count); 6 pr_debug("bus: '%s': %s: probing driver %s with device %s\n", 7 drv->bus->name, __func__, drv->name, dev_name(dev)); 8 WARN_ON(!list_empty(&dev->devres_head)); 9 10 dev->driver = drv; 11 if (driver_sysfs_add(dev)) { 12 printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n", 13 __func__, dev_name(dev)); 14 goto probe_failed; 15 } 16 17 18 if (dev->bus->probe) { 19 ret = dev->bus->probe(dev); 20 if (ret) 21 goto probe_failed; 22 } else if (drv->probe) { 23 ret = drv->probe(dev); 24 if (ret) 25 goto probe_failed; 26 } 27 ...................................
第10行,把驅動和設備對應起來;第18~26行,意思很明顯,從目前來看,第18行的條件不成立而第22行的條件會成立,因此會執行驅動里定義的probe()函數,在這里已經知道了驅動程序里的probe()是什么時候被調用的,后面那些內容是“收尾”工作了。
到這里已經找到了我想要的東西了,也就告一段落了。
