根据LED驱动框架来写LED驱动

何谓驱动框架？
先明白：驱动是谁写的？
(1)驱动开发工程师
(2)内核维护者
驱动编程协作要求？
(1)接口标准化
(2)尽量降低驱动开发者难度
那么什么是驱动框架呢？
(1)内核中驱动部分维护者针对每个种类的驱动设计一套成熟的、标准的、典型的驱动实现，然后把不同厂家的同类硬件驱动中相同的部分抽出来自己实现好，再把不同部分留出接口给具体的驱动开发工程师来实现，这就叫驱动框架。
(1)内核中驱动部分维护者针对每个种类的驱动设计一套成熟的、标准的、典型的驱动实现，然后把不同厂家的同类硬件驱动中相同的部分抽出来自己实现好，再把不同部分留出接口给具体的驱动开发工程师来实现，这就叫驱动框架。
(2)内核维护者在内核中设计了一些统一管控系统资源的体系，这些体系让内核能够对资源在各个驱动之间的使用统一协调和分配，保证整个内核的稳定健康运行。譬如系统中所有的GPIO就属于系统资源，每个驱动模块如果要使用某个GPIO就要先调用特殊的接口先申请，申请到后使用，使用完后要释放。又譬如中断号也是一种资源，驱动在使用前也必须去申请。这也是驱动框架的组成部分。
(3)一些特定的接口函数、一些特定的数据结构，这些是驱动框架的直接表现。

---

内核驱动框架中LED的基本情况：
1.drivers/leds目录，这个目录就是驱动框架规定的LED这种硬件的驱动应该待的地方
2.led-class.c和led-core.c，这两个文件加起来属于LED驱动框架的第一部分，这两个文件是内核开发者提供的，他们描述的是内核中所有厂家的不同LED硬件的相同部分的逻辑
3.leds-xxxx.c，这个文件是LED驱动框架的第2部分，是由不同厂商的驱动工程师编写添加的，厂商驱动工程师结合自己公司的硬件的不同情况来对LED进行操作，使用第一部分提供的接口来和驱动框架进行交互，最终实现驱动的功能

---

九鼎移植的内核中led驱动：
九鼎实际未使用内核推荐的led驱动框架，他实现在：drivers/char/led/x210-led.c

---

所以我们可以以：leds-s3c24xx.c为例来分析驱动框架的使用过程。
分析：
leds-s3c24xx.c中通过调用led_classdev_register来完成我们的LED驱动的注册，而led_classdev_register是在drivers/leds/led-class.c中定义的。所以其实SoC厂商的驱动工程师是调用内核开发者在驱动框架中提供的接口来实现自己的驱动的。
驱动框架的关键点就是：分清楚内核开发者提供了什么，驱动开发者自己要提供什么

---

led驱动框架的分析：
led-core.c
led-class.c

---

led-core.c中的代码：
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/module.h>
#include <linux/rwsem.h>
#include <linux/leds.h>
#include “leds.h”

DECLARE_RWSEM(leds_list_lock);
EXPORT_SYMBOL_GPL(leds_list_lock);

LIST_HEAD(leds_list);
EXPORT_SYMBOL_GPL(leds_list);
分析：定义了两个变量leds_list_lock， leds_list
并用EXPORT_SYMBOL_GPL导出，所有GPL声明的模块都可以使用的。
LIST_HEAD在linux/list.h中。
这个文件中的代码就是定义了两个变量，别的GPL申明的模块也可以使用这两个变量。
EXPORT_SYMBOL：如果不加GPL后缀，则所有的模块都可以使用申明的函数或者变量。

---

led-class.c中代码分析：
subsys_initcall(leds_init);中的subsys_initcall分析：
#define subsys_initcall(fn) __define_initcall(“4”,fn,4)
往下：
#define __define_initcall(level,fn,id)
static initcall_t _initcall##fn##id __used
attribute((section(".initcall" level “.init”))) = fn

modues_init:
往下：
#define module_init(x) __initcall(x);
往下：
#define __initcall(fn) device_initcall(fn)
往下：
#define device_initcall(fn) __define_initcall(“6”,fn,6)
往下：
#define __define_initcall(level,fn,id)
static initcall_t _initcall##fn##id __used
attribute((section(".initcall" level “.init”))) = fn
最后发现他们最后都是调用的一个宏，只是传的level值是不一样的。一个是4，一个是6.
对应之前分析的：我们看INIT_CALLS的定义，在这个文件里面：vim include/asm-generic/vmlinux.lds.h ，
#define INIT_CALLS
VMLINUX_SYMBOL(__initcall_start) = .;
INITCALLS
VMLINUX_SYMBOL(__initcall_end) = .;
7.再看INITCALLS
#define INITCALLS
*(.initcallearly.init)
VMLINUX_SYMBOL(__early_initcall_end) = .;
*(.initcall0.init)
*(.initcall0s.init)
*(.initcall1.init)
*(.initcall1s.init)
*(.initcall2.init)
*(.initcall2s.init)
*(.initcall3.init)
*(.initcall3s.init)
*(.initcall4.init)
*(.initcall4s.init)
*(.initcall5.init)
*(.initcall5s.init)
*(.initcallrootfs.init)
*(.initcall6.init)
*(.initcall6s.init)
(.initcall7.init)
(.initcall7s.init)
所以一个在：(.initcall4.init)，另外一个在(.initcall6.init)
内核在启动过程中需要顺序的做很多事，内核如何实现按照先后顺序去做很多初始化操作。内核的解决方案就是给内核启动时要调用的所有函数归类，然后每个类按照一定的次序去调用执行。这些分类名就叫.initcalln.init。n的值从1到8。内核开发者在编写内核代码时只要将函数设置合适的级别，这些函数就会被链接的时候放入特定的段，内核启动时再按照段顺序去依次执行各个段即可。
经过分析，可以看出，subsys_initcall和module_init的作用是一样的，只不过前者所声明的函数要比后者在内核启动时的执行顺序更早。

---

struct class的定义在：linux/device.h中：定义如下
struct class {
const char *name;
struct module *owner;
struct class_attribute *class_attrs;
struct device_attribute *dev_attrs;
struct kobject *dev_kobj;
int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
char *(*devnode)(struct device *dev, mode_t *mode);
void (*class_release)(struct class *class);
void (*dev_release)(struct device *dev);
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
const struct dev_pm_ops *pm;
struct class_private *p;
};
分析一个函数：__init函数
static struct class *leds_class;
static int __init leds_init(void)
{
leds_class = class_create(THIS_MODULE, “leds”);
if (IS_ERR(leds_class))
return PTR_ERR(leds_class);
leds_class->suspend = led_suspend;
leds_class->resume = led_resume;
leds_class->dev_attrs = led_class_attrs;
return 0;
}
做了那些事：
1.在/sys/class下面创建一个leds的类
2.class数据类型变量leds_class的赋值，函数指针的赋值

led_class_attrs？
什么是attribute，对应将来/sys/class/leds/目录里的内容，一般是文件和文件夹。这些文件其实就是sysfs开放给应用层的一些操作接口（非常类似于/dev/目录下的那些设备文件）
attribute有什么用，作用就是让应用程序可以通过/sys/class/leds/目录下面的属性文件来操作驱动进而操作硬件设备。
attribute其实是另一条驱动实现的路线。有区别于之前讲的file_operations那条线

---

led_classdev_register
调用：
device_create
分析可知，led_classdev_register这个函数其实就是去创建一个属于leds这个类的一个设备。其实就是去注册一个设备。所以这个函数其实就是led驱动框架中内核开发者提供给SoC厂家驱动开发者的一个注册驱动的接口。
当我们使用led驱动框架去编写驱动的时候，这个led_classdev_register函数的作用类似于我们之前使用file_operations方式去注册字符设备驱动时的register_chrdev函数

---

去除九鼎移植的LED驱动
1.九鼎移植的驱动在应用层的接口在/sys/devices/platform/x210-led/目录下，有led1、led2、led3、led4四个设备文件，各自管理一个led。
2.我们可以使用echo 1 > led1，cat led1等方式去访问led设备。
3.要去掉九鼎自己移植的led驱动，要在make menucofig中去掉选择项，然后重新make得到zImage，然后重启时启动这个新的zImage即可

---

下面我们就要参考三星的led-s3c2440.c来根据驱动框架来编写我们的led驱动了。
我们先只关注：led_classdev_register函数的使用，先不关注platform相关的。

int led_classdev_register(struct device *parent, struct led_classdev *led_cdev)，第一个参数是parent的指针，第二个是 struct led_classdev *的。

---

代码：
两个函数的说明：
struct device *device_create(struct class *cls, struct device *parent,
dev_t devt, void *drvdata,
const char *fmt, …)
第一个参数：指定所要创建的设备所从属的类，
第二个参数：是这个设备的父设备，如果没有就指定为NULL，
第三个参数：是设备号，(Major+Minor)
第四个参数：是驱动的数据，
第五个参数：是创建的设备的名字。

#define class_create(owner, name)
({
static struct lock_class_key __key;
__class_create(owner, name, &__key);
})
第一个参数：指定类的所有者是哪个模块，一般是：THIS_MODULE
第二个参数：指定类名，sys/class/下面的名字

struct led_classdev led_cdev1;定义在linux/led.h

led_classdev_register：定义在leds/led.h中

---

根据驱动框架写的第一个驱动:
代码：

#include <linux/init.h>
#include <linux/module.h>
#include <linux/leds.h>
#include <linux/io.h>
#include <mach/regs-gpio.h>
#include <mach/gpio-bank.h>

#define GPJ0CON S5PV210_GPJ0CON
#define GPJ0DAT S5PV210_GPJ0DAT

static struct led_classdev led_cdev1;

static void s5pv210_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
printk(KERN_INFO “s5pv210_led_set\n”);
if (LED_OFF == brightness)
{
iowrite32(((1<<12) | (1<<16) | (1<<20)), GPJ0CON);
iowrite32(((1<<3) | (1<<4) | (1<<5)), GPJ0DAT);
}
else
{
iowrite32(((1<<12) | (1<<16) | (1<<20)), GPJ0CON);
iowrite32(((0<<3) | (0<<4) | (0<<5)), GPJ0DAT);
}
}

static int __init s5pv210_led_init(void)
{
int ret = -1;
led_cdev1.name = “led1”;
led_cdev1.brightness = 0;
led_cdev1.max_brightness = 1;
led_cdev1.brightness_set = s5pv210_led_set;
ret = led_classdev_register(NULL, &led_cdev1);
if (ret)
{
printk(KERN_INFO “led_classdev_register fail\n”);
}
printk(KERN_INFO “led_classdev_register ok\n”);
return 0;
}

static void __exit s5pv210_led_exit(void)
{
led_classdev_unregister(&led_cdev1);
}

module_init(s5pv210_led_init);
module_exit(s5pv210_led_exit);

// MODULE_xxx这种宏作用是用来添加模块描述信息
MODULE_LICENSE(“GPL”); // 描述模块的许可证
MODULE_AUTHOR(“Mark 867439374@qq.com”); // 描述模块的作者
MODULE_DESCRIPTION(“s5pv210 led driver”); // 描述模块的介绍信息
MODULE_ALIAS(“s5pv210_led”); // 描述模块的别名信息

---

代码分析：
static struct led_classdev led_cdev1;
我们需要定义一个led_classdev 的结构体来代表我们一个led设备。
在注册之前，我们需要填充这个结构体,如下：
led_cdev1.name = “led1”;
led_cdev1.brightness = 0;
led_cdev1.max_brightness = 1;
led_cdev1.brightness_set = s5pv210_led_set;
然后使用：led_classdev_register函数注册。
在驱动框架leds_class.c中：会创建一个leds的class。在led_classdev_register函数中，会device_create。所以就会在/sys/class/下面有leds的类，leds的类下面有led1的device。

static struct device_attribute led_class_attrs[] = {
__ATTR(brightness, 0644, led_brightness_show, led_brightness_store),
__ATTR(max_brightness, 0444, led_max_brightness_show, NULL),
#ifdef CONFIG_LEDS_TRIGGERS
__ATTR(trigger, 0644, led_trigger_show, led_trigger_store),
#endif
__ATTR_NULL,
};
这个是将来在/sys/class/leds/led1下面存在的attribute。有brightness和max_brightness。还有其对应的操作方法led_brightness_show、led_brightness_store、led_max_brightness_show。
这些操作方法，我们在led_classdev 可以提供，提供了之后，他就会使用指针的方式去调用我们提供的方法。

---

通过分析看出：
第1：我们写的驱动确实工作了，被加载了，/sys/class/leds/目录下确实多出来了一个表示设备的文件夹。文件夹里面有相应的操控led硬件的2个属性brightness和max_brightness
第2：led-class.c中brightness方法有一个show方法和store方法，这两个方法对应用户在/sys/class/leds/myled/brightness目录下直接去读写这个文件时实际执行的代码。
当我们cat 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中要提供的。

驱动的设计理念：不要对最终需求功能进行假定，而应该只是直接的对硬件的操作。有一个概念就是：机制和策略的问题。在硬件操作上驱动只应该提供机制而不是策略。策略由应用程序来做。