NAND FLASH学习笔记之MTD下nand flash驱动(四)
2014-02-11 15:09
246 查看
转载请注明出处:http://blog.csdn.net/wang_zheng_kai
四、Register到MTD子系统
两种注册方式:(我们需要完成的)
1)直接注册整个flash设备(MTD Device)到MTD。
ret = add_mtd_device(mtd);
2)分partion添加到mtd_table,并将每个partion当成
一个mtd设备注册到MTD。
ret = add_mtd_partitions(mtd, parts,num_part);
其中:
add_mtd_partitions()->add_one_partition()
slave->mtd.xxx= master->mtd.xxx;
add_mtd_device(&slave->mtd);
从master中获得type,read,write等参数。
并将slave作为一个mtd设备添加到mtd_table。
最后注册设备及创建dev下面的设备节点。
五、NAND FLASH驱动层
Linux内核在MTD的下层实现了通用的NAND驱动( 主要通过drivers/mtd/nand/nand_base.c文件实现),因此芯片级的NAND 驱动不再需要实现mtd_info中的read()、write()、read_oob()、write_oob()等成员函数,而主体转移到了nand_chip数据结构。
MTD使用nand_chip数据结构表示一个NANDFlash芯片,这个结构体中包含了关于NAND Flash的地址信息、读写方法、ECC模式、硬件控制等一些底层机制。
驱动实现层:jz4780_nand.c
1)通过platform注册。(加载驱动)
platform_driver_register(&jz4780_nand_driver);
2)探测函数jz4780_nand_probe(重要,驱动实现的第一步)
在probe函数中申请资源、硬件初始化、实现nand_chip结构体中的函数指针以及与NAND芯片进行交互,添加mtd设备到MTD。
3)实现一些nand_base.c没有实现的以及其他的一些操作一些操作如:read_buf()等。
4) remove函数
当任意一方卸载时,会释放资源,当该驱动函数或者驱动函数正在操作的设备被移除时,内核会调用驱动函数中的remove函数调用,进行一些设备卸载相应的操作
5)注销jz4780_nand驱动(卸载驱动)
platform_driver_unregister(&jz4780_nand_driver);
驱动的加载程序流程如下图:
其驱动加载的代码分析如下图所示:
四、Register到MTD子系统
两种注册方式:(我们需要完成的)
1)直接注册整个flash设备(MTD Device)到MTD。
ret = add_mtd_device(mtd);
2)分partion添加到mtd_table,并将每个partion当成
一个mtd设备注册到MTD。
ret = add_mtd_partitions(mtd, parts,num_part);
其中:
add_mtd_partitions()->add_one_partition()
slave->mtd.xxx= master->mtd.xxx;
add_mtd_device(&slave->mtd);
从master中获得type,read,write等参数。
并将slave作为一个mtd设备添加到mtd_table。
最后注册设备及创建dev下面的设备节点。
五、NAND FLASH驱动层
Linux内核在MTD的下层实现了通用的NAND驱动( 主要通过drivers/mtd/nand/nand_base.c文件实现),因此芯片级的NAND 驱动不再需要实现mtd_info中的read()、write()、read_oob()、write_oob()等成员函数,而主体转移到了nand_chip数据结构。
MTD使用nand_chip数据结构表示一个NANDFlash芯片,这个结构体中包含了关于NAND Flash的地址信息、读写方法、ECC模式、硬件控制等一些底层机制。
驱动实现层:jz4780_nand.c
1)通过platform注册。(加载驱动)
platform_driver_register(&jz4780_nand_driver);
2)探测函数jz4780_nand_probe(重要,驱动实现的第一步)
在probe函数中申请资源、硬件初始化、实现nand_chip结构体中的函数指针以及与NAND芯片进行交互,添加mtd设备到MTD。
3)实现一些nand_base.c没有实现的以及其他的一些操作一些操作如:read_buf()等。
4) remove函数
当任意一方卸载时,会释放资源,当该驱动函数或者驱动函数正在操作的设备被移除时,内核会调用驱动函数中的remove函数调用,进行一些设备卸载相应的操作
5)注销jz4780_nand驱动(卸载驱动)
platform_driver_unregister(&jz4780_nand_driver);
驱动的加载程序流程如下图:
其驱动加载的代码分析如下图所示:
NAND驱动的代码分析(一) ----------驱动的加载 Joe device_driver和platform driver Platform device是一种device自己是不会做事情的,要有人为它做事情,那就是platform driver。platform driver遵循linux系统的driver model。对于device的discovery/enumerate都不是driver自己完成的而是由由系统的driver注册机制完成。 driver编写人员只要将注册必须的数据结构初始化并调用注册driver的kernel API就可以了。 接下来来看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 (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *); struct device_driver driver; }; 可见,它包含了设备操作的几个功能函数,同时包含了一个device_driver结构,说明device_driver是 platform_driver的基类。驱动程序中需要初始化这个变量。下面看一下这个变量的定义 121struct device_driver { 122 const char *name; 123 struct bus_type *bus; 124 125 struct module *owner; 126 const char *mod_name; /* used for built-in modules */ 127 128 int (*probe) (struct device *dev); 129 int (*remove) (struct device *dev); 130 void (*shutdown) (struct device *dev); 131 int (*suspend) (struct device *dev, pm_message_t state); 132 int (*resume) (struct device *dev); 133 struct attribute_group **groups; 134 135 struct driver_private *p; 136}; device_driver提供了一些操作接口,但其并没有实现,相当于一些虚函数,由派生类platform_driver进行重载,无论何种类型的 driver都是基于device_driver派生而来的,具体的各种操作都是基于统一的基类接口的,这样就实现了面向对象的设计。 需要注意这两个变量:name和owner。其作用主要是为了和相关的platform_device关联起来,owner的作用是说明模块的所有者,驱动程序中一般初始化为THIS_MODULE。 device_driver结构中也有一个name变量。platform_driver从字面上来看就知道是设备驱动。设备驱动是为谁服务的呢?当然是设备了。内核正是通过这个一致性来为驱动程序找到资源,即 platform_device中的resource。 《一》 jz4780_nand_init static int __init jz4780_nand_init(void) { //创建DebugFS,是一种用于内核调试的虚拟文件系统,内核开发者通过debugfs和用户空间交换数据。 #ifdef CONFIG_DEBUG_FS debugfs_root = debugfs_create_dir(DRVNAME, NULL); if (IS_ERR(debugfs_root)) return PTR_ERR(debugfs_root); #endif return platform_driver_register(&jz4780_nand_driver); } 《二》platform_driver_registe int platform_driver_register(struct platform_driver *drv) { /*设置成platform_bus_type(当前驱动所在的总线,平台设备和平台驱动处在同一条总线上 )这个很重要,因为driver和device是通过bus联系在一起的,具体在本例中是通过platform_bus_type中注册的回调例程和属性来是实现的, driver与device的匹配就是通过 platform_bus_type注册的回调例程platform_match ()来完成的。*/ 表明该 dev 是 platform_bus_type 类型的,并且该 dev 也会被添加到 platform_bus_type 的 devices_kset 容器中和 klist_devices 列表中。 drv->driver.bus = &platform_bus_type; //在really_probe函数中,回调了platform_drv_probe函数 回调函数就是一个通过函数指针调用的函数。如果你把函数的指针(地址)作为参数传递给另一个函数,当这个指针被用来调用其所指向的函数时,我们就说这是回调函数。回调函数不是由该函数的实现方直接调用,而是在特定的事件或条件发生时由另外的一方调用的,用于对该事件或条件进行响应。 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); } 代码中: 1. 设置成 platform_bus_type 这个很重要,因为 driver 和 device 是通过 bus 联系在一起的,具体在本例中是通过 platform_bus_type 中注册的回调例程和属性来是实现的, driver 与 device 的匹配就是通过 platform_bus_type 注册的回到例程mach()来完成的。下面就分析 driver_register()。 《三》 driver_register 不要被上面的platform_drv_XXX吓倒了,它们其实很简单,就是将struct device转换为struct platform_device和struct platform_driver,然后调用platform_driver中的相应接口函数。那为什么不直接调用platform_drv_XXX等接口呢?这就是Linux内核中面向对象的设计思想。device_driver提供了一些操作接口,但其并没有实现,相当于一些虚函数,由派生类platform_driver进行重载,无论何种类型的 driver都是基于device_driver派生而来的,device_driver中具体的各种操作都是基于统一的基类接口的,这样就实现了面向对象的设计。 在此函数中,初始化结构体struct device_driver中的klist_device和unloaded字段,通过klist_device字段, 可以保存此驱动支持的设备链表,通过“完成”接口机制,完成线程间的同步。 int driver_register(struct device_driver *drv) { int ret; struct device_driver *other; BUG_ON(!drv->bus->p); // 如果总线的方法和设备自己的方法同时存在,将打印告警信息,对于platform bus,其没有probe等接口 if ((drv->bus->probe && drv->probe) || (drv->bus->remove && drv->remove) || (drv->bus->shutdown && drv->shutdown)) printk(KERN_WARNING "Driver '%s' needs updating - please use " "bus_type methods\n", drv->name); /*通过驱动的名字查找 driver,如果找到了,说明已经注册过,返回错误代码,后面会 分析*/ other = driver_find(drv->name, drv->bus); if (other) { put_driver(other); printk(KERN_ERR "Error: Driver '%s' is already registered, " "aborting...\n", drv->name); return -EBUSY; } /* 将 driver 加入到 bus 的 kset,并生成些文件夹和链接文件,将程序挂在到总线上,通过总线来驱动程序 ret = bus_add_driver(drv); //将本driver驱动注册登记到drv->bus所在的总线上。 if (ret) return ret; /* 添加 attribute_group,本例中没有设置 drv->groups */ ret = driver_add_groups(drv, drv->groups); if (ret) bus_remove_driver(drv); return ret; } 代码中, 1.正如该例程的英文注释所言,大部分工作在 bus_add_driver()例程中完成。 2. driver_find()例程通过驱动所属 bus 的 driver 容器 drivers_kset 来查找 struct device_driver *driver_find(const char *name, struct bus_type *bus) { // 在 drivers_kset 容器中查找 struct kobject *k = kset_find_obj(bus->p->drivers_kset, name); struct driver_private *priv; if (k) { priv = to_driver(k); return priv->driver; //返回找到的driver } return NULL; } 代码中, 通过 kset_find_obj(bus->p->drivers_kset, name)查找该 driver 的 kobj,其代码如下, struct kobject *kset_find_obj_hinted(struct kset *kset, const char *name,struct kobject *hint) { struct kobject *k; struct kobject *ret = NULL; //锁定自旋锁 spin_lock(&kset->list_lock); if (!hint) goto slow_search; /* end of list detection */ if (hint->entry.next == kset->list.next) goto slow_search; k = container_of(hint->entry.next, struct kobject, entry); if (!kobject_name(k) || strcmp(kobject_name(k), name)) goto slow_search; ret = kobject_get(k); goto unlock_exit; slow_search: list_for_each_entry(k, &kset->list, entry) {// 遍历 kset->list 列表获取 kobj if (kobject_name(k) && !strcmp(kobject_name(k), name)) { // 比较 name 字符 ret = kobject_get(k); // 如果找到就增加引用并返回 break; } } //释放自旋锁 unlock_exit: spin_unlock(&kset->list_lock); if (hint) //这里hint为NULL kobject_put(hint); return ret; } 《四》bus_add_driver(struct device_driver *drv) 显然,所有同类型的 driver 都注册到了 一个 bus->p->drivers_kset->list 中,所以可通过其查找已经注册的 driver。下面分析 bus_add_driver()例程,该代码主要用来将驱动设备注册到bus总线中。 int bus_add_driver(struct device_driver *drv) //将本driver驱动注册登记到drv->bus所在的总线上。 { struct bus_type *bus; struct driver_private *priv; int error = 0; bus = bus_get(drv->bus);//获取总线内容,即前面定义的 if (!bus) return -EINVAL; pr_debug("bus: '%s': add driver %s\n", bus->name, drv->name); priv = kzalloc(sizeof(*priv), GFP_KERNEL); //为驱动私有成员申请内存且清0, 这个结构体中存放着 kobj 相关的数据,主要存放的是私有的数据。 if (!priv) { error = -ENOMEM; goto out_put_bus; } klist_init(&priv->klist_devices, NULL, NULL);//初始化驱动所支持的设备链表 priv->driver = drv; // 将匹配的 driver 指针关联到 dev,以便后续使用 drv->p = priv; // 将 priv 保存到 device_driver, /* 指向 bus 的 drivers_kset 容器,该容器的作用与 device_kset 容器相同,前者是包含所有注册到该 bus 的 driver,后者是包含所有注册到该 bus 的 device。*/ priv->kobj.kset = bus->p->drivers_kset; /*初始化 priv->kobj,并将其添加到 bus->p->drivers_kset 中,在本例中生成/sys/bus/platform/drivers/jz4780_nand 目录,后面会分析 drivers_kset 的初始化及/sys/bus/platform/drivers/目录的生成 */ error = kobject_init_and_add(&priv->kobj, &driver_ktype, NULL,"%s", drv->name); //初始化并添加驱动kobject对象到总线驱动中 if (error) goto out_unregister; if (drv->bus->p->drivers_autoprobe) {// 在 bus_register()例程中已经设置为 1 了 error = driver_attach(drv); // 所以会寻找匹配的 device,后面分析 if (error) goto out_unregister; } // 将 driver 链接到 klist_drivers,方便后续快速查找 driver//将驱动节点加入到总线链表中 klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers); // 将 driver 添加到 module 模块,后面会分析 module_add_driver(drv->owner, drv); /* 生成/sys//sys/bus/platform/drivers/属性文件,其作用与 device 中的 uevent 类似*/ error = driver_create_file(drv, &driver_attr_uevent); if (error) { printk(KERN_ERR "%s: uevent attr (%s) failed\n",__func__, drv->name); } /* 添加 bus 的公有属性文件到/sys//sys/bus/platform/drivers/目录,所有的 driver 都添加 */ error = driver_add_attrs(bus, drv); if (error) { /* How the hell do we get out of this pickle? Give up */ printk(KERN_ERR "%s: driver_add_attrs(%s) failed\n",__func__, drv->name); } if (!drv->suppress_bind_attrs) { /* 如果配置了”CONFIG_HOTPLUG",则生成“bind”和"unbind”属性文件,可用于手动匹 配和移除 device 与 driver 之间的关联 */ error = add_bind_files(drv); if (error) { /* Ditto */ printk(KERN_ERR "%s: add_bind_files(%s) failed\n",__func__, drv->name); } } // 通过 uevent 设置几个环境变量并通知用户空间,以便调用程序来完成相关设置 kobject_uevent(&priv->kobj, KOBJ_ADD); return 0; out_unregister: kobject_put(&priv->kobj); kfree(drv->p); drv->p = NULL; out_put_bus: bus_put(bus); return error; } 代码中, struct driver_private 来存放 kobj 相关的数据,将 struct driver_private 嵌入在 struct device_driver 中。struct driver_private 定义如下: struct driver_private { struct kobject kobj; //代表该bus,里面的kobj是该bus的主kobj,也就是最顶层 struct klist klist_devices; //其作用与devices_kset->list作用相同 struct klist_node knode_bus; struct module_kobject *mkobj; struct device_driver *driver; }; 《五》driver_attach(struct device_driver *drv) //如果总线上的driver是自动probe的话,则将该总线上的driver和device绑定起来。 /** * driver_attach - try to bind driver to devices. * @drv: driver. * Walk the list of devices that the bus has on it and try to * match the driver with each one. If driver_probe_device() * returns 0 and the @dev->driver is set, we've found a * compatible pair. */ int driver_attach(struct device_driver *drv) { /* 遍历 bus 的 klist_devices 列表,对每个 device 使用回调函数__driver_attach()来鉴别是否 和 driver 匹配 */ return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); } EXPORT_SYMBOL_GPL(driver_attach); int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data, int (*fn)(struct device *, void *)) { struct klist_iter i; struct device *dev; int error = 0; if (!bus) return -EINVAL; //设置i klist_iter_init_node(&bus->p->klist_devices, &i, (start ? &start->p->knode_bus : NULL)); //使用i进行遍历 while ((dev = next_device(&i)) && !error) error = fn(dev, data);// 使用回调例程,处理 klist_iter_exit(&i); return error; } EXPORT_SYMBOL_GPL(bus_for_each_dev); //扫描该总线上的每一个设备,将当前driver和总线上的设备进行match,如果匹配成功,则将设备和driver绑定起来。 回调例程__driver_attach() 函数__driver_attach()在调用driver_probe_device()函数前,需要进行线程间的互斥处理。《六》__driver_attach(struct device *dev, void *data) static int __driver_attach(struct device *dev, void *data) { struct device_driver *drv = data; /* * Lock device and try to bind to it. We drop the error * here and always return 0, because we need to keep trying * to bind to devices and some drivers will return an error * simply if it didn't support the device. * driver_probe_device() will spit a warning if there * is an error. */ /* 调用 bus 的 match (),在这里是 platform_bus_type 的 mach(),即 platform_match()例 程 */ if (!driver_match_device(drv, dev)) return 0; if (dev->parent) /* Needed for USB */ device_lock(dev->parent); device_lock(dev); //如果该设备尚没有匹配的driver,则尝试匹配。 if (!dev->driver) driver_probe_device(drv, dev); // 这里开始 probe device_unlock(dev); if (dev->parent) device_unlock(dev->parent); return 0; } 《七》driver_probe_device(struct device_driver *drv, struct device *dev) 在driver_probe_device()函数中,调用了match函数platform_match(),如果它返回0, 表示驱动与设备不一致,函数返回;否则,调用really_probe()函数。 /** * driver_probe_device - attempt to bind device & driver together * @drv: driver to bind a device to * @dev: device to try to bind to the driver * * First, /** * driver_probe_device - attempt to bind device & driver together * @drv: driver to bind a device to * @dev: device to try to bind to the driver * This function returns -ENODEV if the device is not registered, * 1 if the device is bound successfully and 0 otherwise. * This function must be called with @dev lock held. When called for a * USB interface, @dev->parent lock must be held as well. */ int driver_probe_device(struct device_driver *drv, struct device *dev) { int ret = 0; if (!device_is_registered(dev)) //判断dev是否已经注册 return -ENODEV; pr_debug("bus: '%s': %s: matched device %s with driver %s\n", drv->bus->name, __func__, dev_name(dev), drv->name); pm_runtime_get_noresume(dev); pm_runtime_barrier(dev); ret = really_probe(dev, drv); pm_runtime_put_sync(dev); return ret; } 《八》really_probe(struct device *dev, struct device_driver *drv) //在此函数中,回调了我们在jz4780.c文件中实现的探测函数jz4780_nand_probe(),至此,平台驱动的注册过程结束。 static int really_probe(struct device *dev, struct device_driver *drv) { int ret = 0; atomic_inc(&probe_count); //原子锁上锁 pr_debug("bus: '%s': %s: probing driver %s with device %s\n", drv->bus->name, __func__, drv->name, dev_name(dev)); WARN_ON(!list_empty(&dev->devres_head)); dev->driver = drv; // 将匹配的 driver 指针关联到 dev,以便后续使用 if (driver_sysfs_add(dev)) { printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n", __func__, dev_name(dev)); goto probe_failed; } // 如果设置了 dev->bus->probe,则调用,在 platform_bus_type 没有设置 if (dev->bus->probe) { ret = dev->bus->probe(dev); if (ret) goto probe_failed; } else if (drv->probe) { ret = drv->probe(dev); if (ret) goto probe_failed; } // 将 device 添加到 driver 列表中,并通知 bus 上的设备,表明 BOUND_DRIVER。 //设备与驱动绑定后,对系统中已注册的组件进行事件通知。 driver_bound(dev); ret = 1; pr_debug("bus: '%s': %s: bound device %s to driver %s\n", drv->bus->name, __func__, dev_name(dev), drv->name); goto done; probe_failed: devres_release_all(dev); driver_sysfs_remove(dev); dev->driver = NULL; if (ret != -ENODEV && ret != -ENXIO) { /* driver matched but the probe failed */ printk(KERN_WARNING "%s: probe of %s failed with error %d\n", drv->name, dev_name(dev), ret); } /* * Ignore errors returned by ->probe so that the next driver can try * its luck. */ ret = 0; done: atomic_dec(&probe_count); wake_up(&probe_waitqueue); return ret; }
相关文章推荐
- NAND FLASH学习笔记之MTD下nand flash驱动(二)
- NAND FLASH学习笔记之MTD下nand flash驱动(五)
- NAND FLASH学习笔记之MTD下nand flash驱动(三)
- NAND FLASH学习笔记之MTD下nand flash驱动(六)
- NAND FLASH学习笔记之MTD下nand flash驱动(一)
- NAND FLASH学习笔记之MTD下nand flash驱动(七)---我的调试
- NAND FLASH学习笔记之MTD下nand flash驱动(二)————几个重要文件和几个重要的结构体
- 学习笔记 --- LINUX MTD设备之NANDFLASH驱动分析
- 学习笔记 --- LINUX MTD设备之NORFLASH驱动分析
- STM32学习笔记——FSMC 驱动大容量NAND FLASH [复制链接]
- input子系统学习笔记五 按键驱动实例分析上
- ROS学习笔记(二)- ROS驱动机器人实例
- MTD(2)---nand flash的底层驱动代码分析 .
- 文件过滤系统驱动开发Filemon学习笔记
- Zynq-Linux移植学习笔记之11-qspi驱动配置
- 学习Linux驱动的一点笔记
- LCD驱动 学习笔记(二)[型号:SPFD5408]
- 再次学习flash驱动——挖掘不能发现nand flash盘符的原因
- BDA驱动学习笔记(5):APP和Driver的通信
- 【SpringMVC注解开发】案例驱动-包装类型pojo参数绑定 SpringMVC学习笔记(五)