第一部分：字符设备工作过程
1、系统调用和驱动程序的关联
关键结构体：struct file_operation；file_operation结构体的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。
第二部分：字符设备驱动
1、注册字符设备驱动接口
（1）老接口 register_chrdev
__register_chrdev //函数前面加__,说明函数是由内核维护者写的
__register_chrdev_region //用来注册支付设备的主次设备号
cdev_alloc()
cdev_add（）
（2）新接口 register_chrdev_region（自己指定设备号）/alloc_chrdev_region（自己不指定设备号，然系统来分配）仅可用来获取设备号，尚未注册设备 ；
cdevn，结构体，可以实现字符设备驱动程序的注册，相关函数有cdev_alloc（为cdev结构体创建内存空间)、cdev_init、cdev_add（用来注册）、cdev_del
在注册设备的时候可以定义cdev结构体，这种方式分配的内存在数据段，灵活性不够；也可通过定义cdev指针变量，然后通过cdev_alloc申请内存空间，这种方式比较灵活。
register_chrdev_region
__register_chrdev_region
alloc_chrdev_region
__register_chrdev_region
（3）主次设备号
MKDEV，由主设备号和次设备号算出来一个主次设备号
MAJOR，从设备号里面提取出来主设备号
MINOR，从设备号里面提取出来次设备号
（4）内存
全局变量 .data数据段，程序在加载的时候去分配，程序结束的时候数据段的内容才会去释放，数据段里面的内容在程序运行过程中是永久有效的；缺点：内存一直占用，灵活性不够；
局部变量 栈，用的时候申请，不用的时候释放，灵活性太高
malloc 堆，按需分配，申请和释放都需要手工进行
字符设备驱动工作流程：在应用程序打开/dev/text设备文件，在内核中找到这个文件所对应的主次设备号，根据主次设备号可以找到对应的file_operatons结构体
2、自动创建字符设备驱动的设备文件
（1）使用mknod创建设备文件的缺点：手工创建，手工删除，太麻烦
（2）解决方案：udev(嵌入式中用的是mdev)
mdev是一个应用层的软件，由于设备文件在用户空间，所以是在busybox中实现的一个命令。
内核驱动和应用层udev之间有一套信息传输机制（netlink协议）。
应用层启动udev（在跟文件系统的rcS里面）内核驱动中使用相应的接口，驱动在注册和注销时信息会被传给udev，由udev在应用层进行设备文件的创建和删除。
（3）内核驱动设备类相关函数
class_create //创建一个类
device_create //创建一个设备
（4）设备类代码分析
使用class_create创建一个设备类，类名就是根文件系统中sys/class目录下的名字；
uevent 里面存放的就是内核给udev传递信息的地方；
（5）静态映射表建立过程分析
映射表就是map-s5p.h里面的一些宏定义，这些宏定义就是虚拟地址和物理地址的映射关系。
映射表建立函数。该函数负责由映射表来建立linux内核的页表映射关系。在kernel/arch/arm/mach-s5pv210/mach-smdkc110.c中的smdkc110_map_io函数中实现。
s5p_init_io
iotable_init
结论：经过分析，真正的内核移植时给定的静态映射表在arch/arm/plat-s5p/cpu.c中的s5p_iodesc，本质是一个结构体数组，数组中每一个元素就是一个映射，这个映射描述了一段物理地址到虚拟地址之间的映射。这个结构体数组所记录的几个映射关系被iotable_init所使用，该函数负责将这个结构体数组格式的表建立成MMU所能识别的页表映射关系，这样在开机后可以直接使用相对应的虚拟地址来访问对应的物理地址。
开机时调用映射表建立函数：
问题：开机时（kernel启动时）smdkc110_map_io怎么被调用的？
start_kernel
setup_arch
paging_init
devicemaps_init
if (mdesc->map_io)
mdesc->map_io();
第三部分：驱动框架
1、驱动框架的概念
（1）内核中驱动部分维护者针对每种种类的的驱动设计一套成熟的、标准的、典型的驱动实现，然后把不同厂家的同类硬件驱动中的相同的部分抽出来自己实现好，再把不同部分留出接口给具体的驱动开发工程师来实现，这就叫驱动框架。
（2）内核维护者在内核中设计了一些统一管控系统资源的体系，这些体系让内核能够对资源在各个驱动之间的使用统一协调和分配，保证整个内核的稳定健康运行。譬如系统中所有的GPIO就属于系统资源，每个驱动模块如果要使用某个GPIO就要先调用特殊的接口先申请，申请到后使用，使用完后要释放。又譬如中断号也是一种资源，驱动在使用前也必须去申请。这也是驱动框架的组成部分。
(3)一些特定的接口函数、一些特定的数据结构，这些是驱动框架的直接表现。
5.4.2.内核驱动框架中LED的基本情况
5.4.2.1、相关文件
(1)drivers/leds目录，这个目录就是驱动框架规定的LED这种硬件的驱动应该待的地方。
(2)led-class.c和led-core.c，这两个文件加起来属于LED驱动框架的第一部分，这两个文件是内核开发者提供的，他们描述的是内核中所有厂家的不同LED硬件的相同部分的逻辑。
(3)leds-xxxx.c，这个文件是LED驱动框架的第2部分，是由不同厂商的驱动工程师编写添加的，厂商驱动工程师结合自己公司的硬件的不同情况来对LED进行操作，使用第一部分提供的接口来和驱动框架进行交互，最终实现驱动的功能。
5.4.2.2、九鼎移植的内核中led驱动
(1)九鼎实际未使用内核推荐的led驱动框架
(2)drivers/char/led/x210-led.c
5.4.2.3、案例分析驱动框架的使用
(1)以leds-s3c24xx.c为例。leds-s3c24xx.c中通过调用led_classdev_register来完成我们的LED驱动的注册，而led_classdev_register是在drivers/leds/led-class.c中定义的。所以其实SoC厂商的驱动工程师是调用内核开发者在驱动框架中提供的接口来实现自己的驱动的。
(2)驱动框架的关键点就是：分清楚内核开发者提供了什么，驱动开发者自己要提供什么
5.4.2.4、典型的驱动开发行业现状
(1)内核开发者对驱动框架进行开发和维护、升级，对应led-class.c和led-core.c
(2)SoC厂商的驱动工程师对设备驱动源码进行编写、调试，提供参考版本，对应leds-s3c24xx.c
(3)做产品的厂商的驱动工程师以SoC厂商提供的驱动源码为基础，来做移植和调试
5.4.3_4.初步分析led驱动框架源码1_2
5.4.3.1、涉及到的文件
(1)led-core.c
(2)led-class.c
5.4.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的作用是一样的，只不过前者所声明的函数要比后者在内核启动时的执行顺序更早。
2、led_class_attrs
(1)什么是attribute，对应将来/sys/class/leds/目录里的内容，一般是文件和文件夹。这些文件其实就是sysfs开放给应用层的一些操作接口（非常类似于/dev/目录下的那些设备文件）
(2)attribute有什么用，作用就是让应用程序可以通过/sys/class/leds/目录下面的属性文件来操作驱动进而操作硬件设备。
(3)attribute其实是另一条驱动实现的路线。有区别于之前讲的file_operations那条线。
3、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、基于驱动框架写led驱动
第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函数
(1)show方法实际要做的就是读取LED硬件信息，然后把硬件信息返回给我们即可。所以show方法和store方法必会去操控硬件。但是led-class.c文件又属于驱动框架中的文件，它本身无法直接读取具体硬件，因此在show和store方法中使用函数指针的方式调用了struct led_classdev结构体中的相应的读取/写入硬件信息的方法。
(2)struct led_classdev结构体中的实际用来读写硬件信息的函数，就是我们自己写的驱动文件leds-s5pv210.c中要提供的。
驱动的设计理念：不要对最终需求功能进行假定，而应该只是直接的对硬件的操作。有一个概念就是：机制和策略的问题。在硬件操作上驱动只应该提供机制而不是策略。策略由应用程序来做。
5、gpiolib学习
（1）学习重点：gpiolib的建立过程；
gpiolib的使用方法：申请、使用、释放；
gpiolib的架构：涉及哪些目录的哪些文件
（2）主线1：gpiolib的建立
smdkc110_map_io
s5pv210_gpiolib_init 这个函数就是我们gpiolib初始化的函数
（3）struct s3c_gpio_chip
这个结构体是一个GPIO端口的抽象,这个结构体的一个变量就可以完全的描述一个IO端口。
端口和IO口是两个概念。S5PV210有很多个IO口（160个左右），这些IO口首先被分成N个端口（port group），然后每个端口中又包含了M个IO口。譬如GPA0是一个端口，里面包含了8个IO口，我们一般记作：GPA0_0（或GPA0.0）、GPA0_1、
内核中为每个GPIO分配了一个编号，编号是一个数字（譬如一共有160个IO时编号就可以从1到160连续分布），编号可以让程序很方便的去识别每一个GPIO。
6、设备驱动模型简介
（1）类class、总线bus、设备device、驱动driver
代表4个结构体，比如每一个设备都可以用一个device结构体表示，这4个结构体分别用来描述这4个东西，将来用这四个结构体来生产对应结构体类型的变量，每一个结构体类型的变量都能代表一个这种类型的具体的实例。
设备 struct device是硬件设备在内核驱动框架中的抽象
device_register用于向内核驱动框架注册一个设备
通常device不会单独使用，而是被包含在一个具体设备结构体中，如struct usb_device
驱动 struct device_driver是驱动程序在内核驱动框架中的抽象
关键元素1：name，驱动程序的名字，很重要，经常被用来作为驱动和设备的匹配依据
关键元素2：probe，驱动程序的探测函数，用来检测一个设备是否可以被该驱动所管理
（2）Kobject和对象生命周期
kobject是内核里面一个高度抽象的结构体，用来表示内核里面的一个对象，就是内核里面所有对象抽象出来的一个总类
（3）sysfs,虚拟文件系统，在内核空间和用户空间之间建立了一个映射关系。
（4）udev,是为了实现内核空间和用户空间信息的同步，可以让用户空间及时得知内核空间的状况。
（5）设备驱动模型负责统一实现和维护一些特性，譬如：电源管理、热插拔、对象生命周期、用户空间和驱动空间的交互等基础设施。设备驱动模型目的是简化驱动程序编写，但是客观上设备驱动模型本身设计和实现很复杂。
7、设备驱动模型的底层架构
（1）kobject ，linux设备驱动中最原始的，最基本的结构体，这个结构体作为别的结构体中的一个成员的方式存在的，提供一些公用型服务如：对象引用计数、维护对象链表、对象上锁、对用户空间的表示。
原文地址：https://www.cnblogs.com/gzqblogs/p/10133265.html