1.何谓驱动框架
1.1驱动是谁写的
1)驱动开发工程师
2)内核维护者
1.2驱动编程协作要求
1)接口标准化
2)尽量降低驱动开发者难度
1.3到底什么是驱动框架
1)内核中驱动部分维护者针对每个种类的驱动设计一套成熟的、标准的、典型的驱动实现，然后把不同厂家的同类硬件驱动中相同的部分抽出来自己实现好，再把不同部分留出接口给具体的驱动开发工程师来实现，这就叫驱动框架。
2)内核维护者在内核中设计了一些统一管控系统资源的体系，这些体系让内核能够对资源在各个驱动之间的使用统一协调和分配，保证整个内核的稳定健康运行。譬如系统中所有的GPIO就属于系统资源，每个驱动模块如果要使用某个GPIO就要先调用特殊的接口先申请，申请到后使用，使用完后要释放。又譬如中断号也是一种资源，驱动在使用前也必须去申请。这也是驱动框架的组成部分。
3)一些特定的接口函数、一些特定的数据结构，这些是驱动框架的直接表现。
2.内核驱动框架中LED的基本情况
2.1相关文件
1)drivers/leds目录，这个目录就是驱动框架规定的LED这种硬件的驱动应该待的地方。
2)led-class.c和led-core.c，这两个文件加起来属于LED驱动框架的第1部分，这两个文件是内核开发者提供的，他们描述的是内核中所有厂家的不同LED硬件的相同部分的逻辑。
3)leds-xxxx.c，这个文件是LED驱动框架的第2部分，是由不同厂商的驱动工程师编写添加的，厂商驱动工程师结合自己公司的硬件的不同情况来对LED进行操作，使用第一部分提供的接口来和驱动框架进行交互，最终实现驱动的功能。
2.2九鼎移植的内核中led驱动
1)九鼎实际未使用内核推荐的led驱动框架
2)drivers/char/led/x210-led.c
2.3案例分析驱动框架的使用
1)以leds-s3c24xx.c为例。leds-s3c24xx.c中通过调用led_classdev_register来完成我们的LED驱动的注册，而led_classdev_register是在drivers/leds/led-class.c中定义的。所以其实SoC厂商的驱动工程师是调用内核开发者在驱动框架中提供的接口来实现自己的驱动的。
2)驱动框架的关键点就是：分清楚内核开发者提供了什么，驱动开发者自己要提供什么
2.4典型的驱动开发行业现状
1)内核开发者对驱动框架进行开发和维护、升级，对应led-class.c和led-core.c
2)SoC厂商的驱动工程师对设备驱动源码进行编写、调试，提供参考版本，对应leds-s3c24xx.c
3)做产品的厂商的驱动工程师以SoC厂商提供的驱动源码为基础，来做移植和调试
3.初步分析led驱动框架源码
3.1涉及到的文件
1)led-core.c
2)led-class.c
3.2.subsys_initcall
1)经过基本分析，发现LED驱动框架中内核开发者实现的部分主要是led-class.c
2)我们发现led-class.c就是一个内核模块，对led-class.c分析应该从下往上，遵从对模块的基本分析方法。
3)为什么LED驱动框架中内核开发者实现的部分要实现成一个模块？因为内核开发者希望这个驱动框架是可以被装载/卸载的。这样当我们内核使用者不需要这个驱动框架时可以完全去掉，需要时可以随时加上。
4)subsys_initcall是一个宏，定义在linux/init.h中。经过对这个宏进行展开，发现这个宏的功能是：将其声明的函数放到一个特定的段：.initcall4.init。
subsys_initcall
__define_initcall("4",fn,4)
5)分析module_init宏，可以看出它将函数放到了.initcall6.init段中。
module_init
__initcall
device_initcall
__define_initcall("6",fn,6)
6)内核在启动过程中需要顺序的做很多事，内核如何实现按照先后顺序去做很多初始化操作。内核的解决方案就是给内核启动时要调用的所有函数归类，然后每个类按照一定的次序去调用执行。这些分类名就叫.initcalln.init。n的值从1到8。内核开发者在编写内核代码时只要将函数设置合适的级别，这些函数就会被链接的时候放入特定的段，内核启动时再按照段顺序去依次执行各个段即可。
7)经过分析，可以看出，subsys_initcall和module_init的作用是一样的，只不过前者所声明的函数要比后者在内核启动时的执行顺序更早。
3.3led_class_attrs
1)什么是attribute，对应将来/sys/class/leds/目录里的内容，一般是文件和文件夹。这些文件其实就是sysfs开放给应用层的一些操作接口（非常类似于/dev/目录下的那些设备文件）
2)attribute有什么用，作用就是让应用程序可以通过/sys/class/leds/目录下面的属性文件来操作驱动进而操作硬件设备。
3)attribute其实是另一条驱动实现的路线。有区别于之前讲的file_operations那条线。
3.4.led_classdev_register
led_classdev_register
device_create
1)分析可知，led_classdev_register这个函数其实就是去创建一个属于leds这个类的一个设备。其实就是去注册一个设备。所以这个函数其实就是led驱动框架中内核开发者提供给SoC厂家驱动开发者的一个注册驱动的接口。
2)当我们使用led驱动框架去编写驱动的时候，这个led_classdev_register函数的作用类似于我们之前使用file_operations方式去注册字符设备驱动时的register_chrdev函数。
4.在内核中添加或去除某个驱动
4.1去除九鼎移植的LED驱动
1)九鼎移植的驱动在应用层的接口在/sys/devices/platform/x210-led/目录下，有led1、led2、led3、led4四个设备文件，各自管理一个led。
2)要去掉九鼎自己移植的led驱动，要在make menucofig中去掉选择项，然后重新make得到zImage，然后重启时启动这个新的zImage即可。
3)新的内核启动后，如果/sys/devices/platform/目录下已经没有了x210-led这个目录，就说明我们去掉这个驱动成功了。
4)为什么make menuconfig就能去掉这个驱动？
4.2添加led驱动框架支持
当前内核中是没有LED驱动框架的，我们要去添加它。
4.3.sysfs中的内容分析
4.4.后续展望：完成leds-x210.c
5.基于驱动框架写led驱动
5.1分析
1)参考哪里？ drivers/leds/leds-s3c24xx.c
2)关键点：led_classdev_register
5.2动手写led驱动模块
5.3代码实践
#include <linux/module.h> // module_init module_exit
#include <linux/init.h> // __init __exit
#include <linux/fs.h>
#include <asm/uaccess.h>
#include <mach/regs-gpio.h>
#include <mach/gpio-bank.h> // arch/arm/mach-s5pv210/include/mach/gpio-bank.h
#include <linux/string.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/leds.h>
static struct led_classdev mydev;
static void s5pv210_led_set(struct led_classdev *led_cdev, enum led_brightness brightness)
{
printk(KERN_INFO "s5pv210_led_set.\n");
}
static int __init s5pv210_led_init(void)
{
//驱动安装时调用该函数
//使用函数的目的就是去使用led驱动框架提供的设备注册函数来注册一个设备
int ret = -1;
mydev.name = "led1";
mydev.brightness = 0;
mydev.brightness_set = s5pv210_led_set;
ret = led_classdev_register(NULL, &mydev);
if (ret < 0) {
printk(KERN_ERR "led_classdev_register failed\n");
return ret;
}
return 0;
}
static void __exit s5pv210_led_exit(void)
{
led_classdev_unregister(&mydev);
}
module_init(s5pv210_led_init);
module_exit(s5pv210_led_exit);
// MODULE_xxx这种宏作用是用来添加模块描述信息
MODULE_AUTHOR("tom");
MODULE_DESCRIPTION("S5PV210 LED driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("s5pv210_led");
1)调试
2)分析
通过分析看出：
第1：我们写的驱动确实工作了，被加载了，/sys/class/leds/目录下确实多出来了一个表示设备的文件夹。文件夹里面有相应的操控led硬件的2个属性brightness和max_brightness
第2：led-class.c中brightness方法有一个show方法和store方法，这两个方法对应用户在/sys/class/leds/myled/brightness目录下直接去读写这个文件时实际执行的代码。
当我们show brightness时，实际就会执行led_brightness_show函数
当我们echo 1 > brightness时，实际就会执行led_brightness_store函数
3)show方法实际要做的就是读取LED硬件信息，然后把硬件信息返回给我们即可。所以show方法和store方法必要要会去操控硬件。但是led-class.c文件又属于驱动框架中的文件，它本身无法直接读取具体硬件，因此在show和store方法中使用函数指针的方式调用了struct led_classdev结构体中的相应的读取/写入硬件信息的方法。
4)struct led_classdev结构体中的实际用来读写硬件信息的函数，就是我们自己写的驱动文件leds-s5pv210.c中要提供的。
5.4添加硬件操作
#include <linux/module.h> // module_init module_exit
#include <linux/init.h> // __init __exit
#include <linux/fs.h>
#include <asm/uaccess.h>
#include <mach/regs-gpio.h>
#include <mach/gpio-bank.h> // arch/arm/mach-s5pv210/include/mach/gpio-bank.h
#include <linux/string.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/leds.h>
#define GPJ0CON S5PV210_GPJ0CON
#define GPJ0DAT S5PV210_GPJ0DAT
static struct led_classdev mydev;
static void s5pv210_led_set(struct led_classdev *led_cdev, enum led_brightness value)
{
printk(KERN_INFO "s5pv210_led_set.\n");
//这里根据用户设置的值来操作硬件
//用户设置的值就是value
if (value == LED_OFF)
{
//用户给了个0，希望LED灭
writel(0x11111111, GPJ0CON);
writel(((1<<3) | (1<<4) | (1<<5)), GPJ0DAT);
}
else
{
//用户给的非零，希望LED亮
writel(0x11111111, GPJ0CON);
writel(((0<<3) | (0<<4) | (0<<5)), GPJ0DAT);
}
}
static int __init s5pv210_led_init(void)
{
//驱动安装时调用该函数
//使用函数的目的就是去使用led驱动框架提供的设备注册函数来注册一个设备
int ret = -1;
mydev.name = "led1";
mydev.brightness = 0;
mydev.brightness_set = s5pv210_led_set;
ret = led_classdev_register(NULL, &mydev);
if (ret < 0) {
printk(KERN_ERR "led_classdev_register failed\n");
return ret;
}
return 0;
}
static void __exit s5pv210_led_exit(void)
{
led_classdev_unregister(&mydev);
}
module_init(s5pv210_led_init);
module_exit(s5pv210_led_exit);
// MODULE_xxx这种宏作用是用来添加模块描述信息
MODULE_AUTHOR("tom");
MODULE_DESCRIPTION("S5PV210 LED driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("s5pv210_led");
5.5在驱动中将4个LED分开
1)好处。驱动层实现对各个LED设备的独立访问，并向应用层展示出4个操作接口led1、led2、led3、led4，这样应用层可以完全按照自己的需要对LED进行控制。
驱动的设计理念：不要对最终需求功能进行假定，而应该只是直接的对硬件的操作。有一个概念就是：机制和策略的问题。在硬件操作上驱动只应该提供机制（单纯提供应用机制）而不是策略（应用层根据需求来操作）。策略由应用程序来做。
2)如何实现
5.6和leds-s3c24xx.c的不同
5.7gpiolib引入
1)一个事实：很多硬件都要用到GPIO、GPIO会复用
2)如果同一个GPIO被2个驱动同时控制了，就会出现bug
3)内核提供gpiolib来统一管理系统中所有GPIO
4)gpiolib本身属于驱动框架的一部分
1217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
