写之前,先看一张图:
上次说了LED驱动程序,Linux自身也携带了LED驱动,且是脱离平台的,即LED子系统.操作起来十分简单.但是它的实质却不是那么容易,研究了一个晚上,终于明白了其中一个文件的功能啦,机led-class.c文件.现在分享一下.
其实LED的驱动位于内核driver/leds目录下.核心文件有:led-class.c leds-s3c24xx.c、leds-gpio.c .先看其中一个文件 led-core.c文件.
一看就知道和类class脱不了关系.class有何作用呢?首先何所谓类呢?就是一组设备具有共同性而抽象出来的.其实leds-gpio.c和leds-s3c24xx.c功能都是差不多,两者是并列的,他们都共有的功能是在class里面实现的.在led-class.c文件实现的功能总的来说就是先建立一个类leds,然后在该类下建立一个设备节点,最后就在该设备节点下载建立几个属性文件.而建立类的交给函数leds_init(void)来完成,而在该类下建立设备节点,以及在该节点下建立属性文件,并对属性文件实现读写操作.
现在我们先看看第一个,就是init加载文件,第一句也是核心句,就是建立一个类leds,并且函数返回值赋值给了led_cdev->dev,即led_cdev->dev=class_create(THIS_MODULE, "leds"),这个将在sys目录下产生文件即产生leds类的文件名,第一个参数指定所属的模块,第二个指定了设备的名字.
而接下来的,第二句IS_ERR(leds-class)就是判断leds-class是否正确产生.接下来的都是函数指针.leds_class->suspend = led_suspend等就是函数指针啦,上面都有具体函数实现.其中suspend()是在设备休眠时调用,resume()是恢复设备时调用.第一个函数suspend()函数的实现,其实它就是调了brightness_set(led_cdev, 0)函数,所以就说说这个函数.这个函数是数据结构体led_classdev里的成员,是指向一个函数,在哪里指向呢?在leds-gpio.c里的那时候,指向gpio_led_set函数,其实实现就是对level变量赋值.而在leds-s3c24xx.c也差不多.总而来说,实现的供能就是设备挂起时候,就level赋一个值,0还是1就根据你的active_low的选择啦.现在说一下resume(),其实也等同上面一样,最终用led_cdev->brightness赋值给level.到这里leds_init函数就OK啦,最后通过subsys_initcall(leds_init)使得eds_init在系统启动时候就会被初始化啦.
总结一下,leds_init函数在系统启动的时候就会被调用.实现的功能就是在sys/class目录下生成leds类目录,还有就是实现挂起和恢复时候,执行brightness_set(led_cdev, *)函数.
接下来就主要剩下led_classdev_register函数.
前面说了就是产生几个文件.其中第一个就是设备节点.该函数第一句
led_cdev->dev = device_create(leds_class, parent, 0, led_cdev, "%s", led_cdev->name);
函数原型
device_create(struct class *class, struct device *parent,dev_t devt, void *drvdata, const char *fmt, ...),
看看代码实现,一个主要函数就是dev = device_create_vargs(class, parent, devt, drvdata, fmt, vargs),就是实现在对应目录下产生设备节点,那个目录,先看看各个参数意思,第一个参数指定所要创建的设备所从属的类,第二个参数是这个设备的父设备,如果没有就指定为NULL,第三个参数是设备号,第四个参数是设备名称,第五个参数是从设备号.我们看一下实参,第一个实参leds_class,这个在哪里出现的呢?在前面leds_init函数的建立类的返回值,所以其实就是在前面的leds类下建立设备文件节点.
接下来的一句也至关重要,device_create_file函数,添加属性文件,添加了几个文件,我们就那其中一
个dev_attr_brightness来讲,这个属性在哪里实现?上面有 DEVICE_ATTR(brightness, 0644, led_brightness_show, led_brightness_store),其中后面两个参数就是实现对该属性文件的读写操作,两个操作都有具体函数实现.说具体点就是,对该属性文件读操作时候,即使用cat命令对该属性文件操作,内核会自动调用led_brightness_show.同理,使用echo命令就调用led_brightness_store函数现在我们就看看这些文件是会放在哪里.
现在先把代码剖出来
int led_classdev_register(struct device *parent, struct led_classdev *led_cdev) { led_cdev->dev = device_create(leds_class, parent, 0, led_cdev, "%s", led_cdev->name); rc = device_create_file(led_cdev->dev, &dev_attr_brightness); }
其实这个函数使用EXPORT_SYMBOL_GPL(led_classdev_register)导出来,在leds-gpio.c和leds-s3c24xx.c中调用.
我们跟踪一下led_classdev_register函数.在leds-gpio.c就有调用到,如下侦测函数
gpio_led_probe(struct platform_device *pdev)
其中调用
ret = create_gpio_led(&pdata->leds[i], &leds_data[i], &pdev->dev, pdata->gpio_blink_set);
查看
create_gpio_led(const struct gpio_led *template,struct gpio_led_data *led_dat, struct device *parent,int (*blink_set)(unsigned, unsigned long *, unsigned long *))
可知,其就调用ret = led_classdev_register(parent, &led_dat->cdev);
前面我们说了建立设备节点,现在再细讲一下.我们主要看看parent指向的是pdev->dev.由于pdev是平台设备,所以得关系到平台设备问题.其中pdev->dev对应平台设备下的设备.所以呢,对于设备节点的设备名,跟踪一下leds-gpio.c代码,就知道leds-gpio.c里的cdev就对应上面的led_cdev
led_dat->cdev.name = template->name; //在函数creat_gpio_led
而 template有对应于pdata->leds[i]
struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
简而言之,就是在在gpio_led_probe函数中,获取平台信息platform_data,作为参数传给函数creat_gpio_led的template参数,最后通过该参数付给了led_dat->cdev.name.
所以创建的dev节点的名字由你的平台设备的信息决定的.
现在再来看看在哪里生成属性文件,看函数
device_create_file(led_cdev->dev, &dev_attr_brightness);
主要是看参数led_cdev->dev,这个又是指向哪里,其实就是建立设备节点时候的返回值,可以看看上面.所以就在设备节点目录下建立属性文件,当然后面几个建立属性文件都一样.
说道这里,led-class.c就完啦,剩下没讲的函数要不就是属性读写函数,要不就是卸载函数,对于属性文件就到我们后面的移植篇再做讲解.总结一下,一般类来说,用class_creat加你类,在device_creat在类目录下建立设备文件,还可以在设备节点下建立属性文件,实现对设备的操作,但是该操作一般就是读写,是通过命令实现的.
好啦,上米哦按那张图就展示了在class下建立4个设备节点:led0-led4,每个设备节点下建立属性文件,其中有一个brigtness,往这个文件执行命令,cat是读出,echo是写入,如:我的板子执行echo 1 >brightness时候,第一颗灯亮.执行echo 0 >brightness时候,第一颗灯不亮.对于为什么会亮,会什么又会灭,在LED移植篇在讲解.
但是这里还是有点问题:我在platform设备明明就只有led0-led4四个设备节点,但是怎么会有led0-led7八个呢,待解..........................................
接下来就差leds-gpio.c(leds-s3c24xx.c和leds_gpio.c)是一样,代码页差不多,,里面主要就是platform模型,即涉及到存放什么硬件资源内核,怎么存放,然后我们又怎么去取出来.......
本文转自:http://blog.csdn.net/shiyi_2012/article/details/7456165