一.linux设备驱动的作用
内核：用于管理软硬件资源，并提供运行环境。如分配4G虚拟空间等。
linux设备驱动：是连接硬件和内核之间的桥梁。
linux系统按个人理解可按下划分：
应用层：包括POSIX接口，LIBC，图形库等，用于给用户提供访问内核的接口。属于用户态，ARM运行在用户模式(usr)或者系统模式(sys)下。
内核层：应用程序调用相关接口后，会通过系统调用，执行SWI指令切换ARM的工作模式到超级用户(svc)模式下，根据用户函数的要求执行相应的操作。
硬件层：硬件设备，当用户需要操作硬件时，内核会根据驱动接口操作硬件设备
图结构如下：
举一个相对比较邪恶的类比：
在深圳的酒店经常会在门缝看到一些卡片，上面说可以通过打电话送货上门提供某中服务。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
二.内核代码树介绍
linux-2.6.29
｜－arch : 包含和硬件体系结构相关的代码
｜－block : 硬盘调度算法，不是驱动
｜－firmware : 固件，如BOIS
｜－Documentation: 标准官方文档
｜－dirver : linux设备驱动
｜－fs : 内核所支持的文件体系
｜－include ：头文件。linux/module.h linux/init.h 常用库。
｜－init ：库文件代码，C库函数在内核中的实现。
init/main.c ->start_kernel->内核执行第一条代码
｜－ipc : 进程件通信
｜－mm ：内存管理
｜－kernel : 内核核心部分，包括进程调度等
｜－net ：网络协议
｜－sound : 所有音频相关
｜
其中，跟设备驱动有关并且经常查阅的文件夹有：
init
include : linux, asm-arm
drivers:
arch: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
三.内核补丁：
补丁一般都是基于某个版本内核生成的，用于升级旧内核。
打补丁需要注意：
1.对应版本的补丁只能用于对应版本的内核。
2.如果在已打补丁的内核再打补丁，需要先卸载原来补丁。
打补丁的方法：
1.制作补丁：
diff -Nur linux-2.6.30/ linux-2.6.30.1/ > linux-2.6.30.1.patch
//N为新加的文件全部修改
//linux-2.6.30 旧版本
//linux-2.6.30.1 新版本
//目标补丁
2.打补丁：
cd linux-2.6.30 //！！注意在原文件夹的目录中打补丁
patch -p1 < ../linux-2.6.30.1.patch //-p1是忽略一级目录
3.恢复：
cd linux-2.6.30 //！！注意在原文件夹的目录中打补丁
patch -R < ../linux-2.6.30.1.patch //撤销补丁xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
四.内核中的Makefile：
对于内核，Makefile分为5类：
Documentation/kbuild/makefiles.txt描述如下：
50 The Makefiles have five parts:
51
52 Makefile 总Makefile，控制内核的编译
53 .config 内核配置文件，配置内核时生成，如make menuconfig后
54 arch/$(ARCH)/Makefile 对应体系结构的Makefile
55 scripts/Makefile.* Makefile共用的规则
56 kbuild Makefiles 各子目录下的Makefile，被上层的Makefile调用。
简单来说，编译内核会执行以下两步骤，它们分别干了以下的事情。
1一般的，我们会拷贝一个对应体系结构的配置文件到主目录下并改名为 .config，这样就在make menuconfig生成的图形配置中已经有了一些默认的配置，减少用户的劳动量。不过这一步不做也没关系的。
2.make menuconfig
2.1、由总Makefile决定编译的体系结构(ARCH). 编译工具(CROSS_COMPILE)，并知道
需要进去哪些内核根下的哪些目录进行编译。
2.2、由arch/$(ARCH)/Makefile,决定arch/$(ARCH)下还有的哪些目录和文件需要编译。
2.3、知道了需要编译的目录后，递归的进入哪些目录下，读取每一个Kconfig的信息，
生成了图形配置的界面。
2.4、通过我们在图形配置界面中选项为[*]、[M]或者[]。
2.5、保存并退出配置，会根据配置生成一份新的配置文件.config，并在同时生成
include/config/auto.conf（这是.config的去注释版）。文件里面保存着CONFIG_XXXX等
变量应该取y还是取m。
3.make
3.1、根据Makefile包含的目录和配置文件的要求，进去个子目录进行编译，最后会在各
子目录下生成一个.o或者.a文件，然后总Makefile指定的连接脚
本 arch/$(ARCH)/kernel/vmlinux.lds生成vmlinux，并通过压缩编程bzImage，或者按要
求在对应的子目录下编译成模块。。
但是，具体是怎么生成配置文件的呢？
注：我使用的内核是2.6.29。
1.在总Makefile中，根据以下语句进入需要编译的目录
470 # Objects we will link into vmlinux / subdirs we need to visit
471 init-y := init/
472 drivers-y := drivers/ sound/ firmware/
473 net-y := net/
474 libs-y := lib/
475 core-y := usr/
476 endif # KBUILD_EXTMOD
639 core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
上面说明了，根目录下的init、driver、sound、firmware、net、lib、usr等目录，在编译时都会进去读取目录下的Makefile并进行编译。
2.在总Makefile中包含的目录还是不够的，内核还需要根据对应的CPU体系架构，
决定还需要将哪些子目录将要编译进内核。在总Makefile中有一个语句：
529 include $(srctree)/arch/$(SRCARCH)/Makefile //在这里，我定义SRCARCH = arm
可以看出，在总Makefile中进去读取相应体系结构的Makefile->arch/$(SRCARCH)/Makefile。arch/$(SRCARCH)/Makefile中指定arch/$(SRCARCH)路径下的哪些子目录需要被编译。
在arch/arm/Makefile 下：
95 head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
187 # If we have a machine-specific directory, then include it in the build.
188 core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
189 core-y += $(machdirs) $(platdirs)
190 core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
191 core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
192 core-$(CONFIG_VFP) += arch/arm/vfp/
193
194 drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
195
196 libs-y := arch/arm/lib/ $(libs-y)
上面看到，指定需要进入arch/arm/kernel/、arch/arm/mm/、arch/arm/common/ 等目录编译，至于
core-y、core-$(CONFIG_FPE_NWFPE)这些是什么东西呢？
其中，y表示编译成模块，m表示编译进内核(上面没有，因为默认情况下ARM全部编译进内核)，但$(CONFIG_OPROFILE)又是什么呢？这些是根据用户在make menuconfig中设置后，生成的值赋给了CONFIG_OPROFILE。
3.那make menuconfig后的配置信息是怎么来的？
这是由各子目录下的Kconfig提供选项功用户选择并配置。
如arch/arm/Kconfig。所有的配置都是根据arch/$(ARCH)/Kconfig文件通过Kconfig的语法source 读取各个包含的子目录Kconfig来生成一个配置界面。每个Makefile目录下都有一个对应的
Kconfig文件，用于生成配置界面来给用户决定内核如何配置，配置后会确定一个。 CONFIG_XXX 的的值（如上面的CONFIG_OPROFILE），来决定编译进内核，还是编译成模块或者不编译。
如在arch/arm/Kconfig下：
595 source "arch/arm/mach-clps711x/Kconfig"
596
597 source "arch/arm/mach-ep93xx/Kconfig"
598
599 source "arch/arm/mach-footbridge/Kconfig"
600
601 source "arch/arm/mach-integrator/Kconfig"
602
603 source "arch/arm/mach-iop32x/Kconfig"
604
605 source "arch/arm/mach-iop33x/Kconfig"
这些就是用来指定，需要读取以下目录下的Kconfig文件来生成一个使用make menuconfig时的配置界面。
至于子目录下的Kconfig是怎么样的，待会介绍。
总结Kconfig的作用：
3.1.在make menuconfig下可以配置选项;
3.2.在.config中确定CONFIG_XXX的的值。
4.只是读取以上的两个Makefile还是不够了，内核还会把包含的子目录一层一层的读取它里面的
Makefile和Kconfig。
上面啰啰嗦嗦地讲了这么久，无非就是想说，内核的编译并不是一个Makefile搞定的，需要通过根目录下的总Makefile来包含一下子Makefile（不管是根目录下的子目录还是/arch/arm中的子目录）。而Kconfig，为用户提供一个交互界面来选择如何配置并生成配置选项。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
五、子目录下的Makefile和Kconfig
上面我一直介绍的都是两个比较大的Makefile——总Makefile和arch/$(ARCH)/Makefile。接下来看一下实例。
一、在makefile中，y表示编译进内核，m表示编译成模块，不写代表不编译。所以，配置最简
单的方法就是，直接修改子目录的Makefile 。
先看看arch/arm/Makefile：
/*arch/arm/mach-s3c2440/Makefile */
12 obj-$(CONFIG_CPU_S3C2440) += s3c2440.o dsc.o
13 obj-$(CONFIG_CPU_S3C2440) += irq.o
14 obj-$(CONFIG_CPU_S3C2440) += clock.o //配置2440的时钟进入模块
15 obj-$(CONFIG_S3C2440_DMA) += dma.o
如果我要取消s3c2440的时钟(当然这是必须要开的，只是举例)。可以直接修改
arch/arm/mach-s3c2440/Makefile 将obj-$( CONFIG_CPU_S3C2440) += clock.o改为
obj- += clock.o
如果你想编译成模块也可以修改成：
obj-m += clock.o
在这里CONFIG_CPU_S3C2440的值默认是y，所以内核是要将时钟编译进内核的。也许有人会问，那我直接修改CONFIG_CPU_S3C2440的值为m不就可以将时钟编译成模块了，何必修改
Makefile这么麻烦呢？的确是这样，只要我们通过在”make menuconfig”的界面中配置后就能够改变CONFIG_CPU_S3C2440的值。接下来看看如何实现。
二、在一般的编译内核时，我们都是通过”make menuconfig”进入图形界面面配置的，接下来我实现一下如何将一个选项加入到图形配置界面中。
看看具体实现的步骤：
以下的执行环境是在PC机上，我使用的内核是linux-2.6.29：
2.1.进入内核目录
cd linux-2.6.29
2.2. 在driver目录下模拟一个名为test1驱动的文件夹
mkdir driver/test1
2.3. 在目录下随便些一个C文件，只要不报错。
vim test1.c
我的test1.c如下：
1 void foo()
2 {
3 ;
4 }
2.4vim Makefile //在目录下编写一个简单的Makefile
Makefile文件编写如下：
obj-$(CONFIG_TEST1) += test1.o
CONFIG_TEST1是决定test1是否编译进内核或者编译成模块的。这就是通过同一目录下的Kconfig来在配置界面中生成选项，由用户在make menuconfig中选择。
2.5所以还要同一目录下写一个Kconfig：
vim Kconfig
Kconfig修改如下：
menu "test1 driver here" //这是在图形配置显示的
config TEST1
bool "xiaobai test1 driver" //这同样也是在图形配置显示的
help
This is test1 //这个也是在图形配置显示的。
说白了，就是在图形配置的driver下多了一个配置选项，用户配置后将 CONFIG_TEST1的值存放在.config中，Makefile通过读取.config的去注释版include/config/auto.conf读取到CONFIG_TEST 的值，再进行编译。
但是，以上几步还不能达到目的，因为虽然在总Makefile中已经包含了目录driver,但是driver目录的Makefile中并没有包含test目录。因此需要在driver/Makefile中添加：
103 obj-$(CONFIG_PPC_PS3) += ps3/
104 obj-$(CONFIG_OF) += of/
105 obj-$(CONFIG_SSB) += ssb/
106 obj-$(CONFIG_VIRTIO) += virtio/
107 obj-$(CONFIG_STAGING) += staging/
108 obj-y += platform/
109 obj-$(CONFIG_TEST1) += test1/ //这是我添加的
虽然Makefile中已经包含了，但这样还是不行。因为当需要配置ARM时， ARM结构下的Kconfig 并没有包含test的Kconfig。这样的话就不会出现在图形配置界面中，因此在arch/arm/Kconfig中添加：
1230 menu "Device Drivers" //要在Device Drivers这个选项里面添加
1231
1232 source "drivers/base/Kconfig"
1233
1234 source "drivers/connector/Kconfig"
。。。。。。。。
1330 source "drivers/test/Kconfig" //这是我添加的
1331
1332 endmenu
大功告成！
这样，make menuconfig界面写的Driver Devices下就多了一个 "test1 friver here"的目录，里面有一个配置选项"xiaobai test1 driver"。
Kconfig文件的语法在documentation/kbuild/kconfig-language.txt文件中有详细的讲解，上面我只是简单实现了一下，都是皮毛。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
六.内核和模块的编译
编译内核很简单，只需要配置完毕后执行make命令，将指定的文件编译进内核
bzImage或者编译成模块。
make = make bzImage + make modules
因此如果值编译内核，即只编译配置文件中-y选项，可以直接用命令
make bzImage
如果值编译模块，即只编译配置文件中的-m选项，可以之直接使用命令
make modules
模块可以编译当然也可以清除，使用命令
make modules clean
如果只想单独编译一个模块，可以使用命令
make M=drivers/test/ modules //只单独编译drivers/test中的.ko
make M=drivers/test/ modules clean //清除
上面的是在内核目录下的操作，但当我写驱动时，我并不可能在内核目录下编
写，但我编译时却要依赖内核中的规则和Makefile，所以就有了以下的方法，
同时这也是一般的编写驱动时Makefile的格式。
指定内核Makefile并单独编译
make -C /root/linux-2.6.29 M=`pwd` module
make -C /root/linux-2.6.29 M=`pwd` module clean
//-C 指定内核Makefile的路径，可以使用相对路径。
//-M 指定要编译的文件的路径，同样课使用相对路径。
编译生成的模块可以指定存放的目录
make -C /root/linux-2.6.29 M=`pwd` modules_install INSTALL_MOD_PATH=/nfsroot xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
七、总结
说了这么久估计都说糊涂了，其实我只是想表达一下内核编译时大体上究竟是怎么样的一个过程。
我以编译S3C2440的内核为例再说一遍：
1一般我们会想将一份S3C2440的默认配置拷贝到内核跟目录下并改名为.config。
2.make menuconfig
2.1、由总Makefile决定编译的体系结构(ARCH). 编译工具(CROSS_COMPILE)，并知道需要进去
哪些内核根下的哪些目录进行编译。
2.2、由arch/$(ARCH)/Makefile,决定arch/$(ARCH)下还有的哪些目录和文件需要编译。
2.3、知道了需要编译的目录后，递归的进入哪些目录下，读取每一个Kconfig的信息，生成了图
形配置的界面。
2.4、通过我们在图形配置界面中选项为[*]、[M]或者[]。
2.5、保存并退出配置，会根据配置生成一份新的配置文件.config，并在同时生成
include/config/auto.conf（这是.config的去注释版）。文件里面保存着CONFIG_XXXX等变量应该取y还是取m。
3.make
3.1、根据Makefile包含的目录和配置文件的要求，进去个子目录进行编译，最后会在各子目录下生
成一个.o或者.a文件，然后总Makefile指定的连接脚本 arch/$(ARCH)/kernel/vmlinux.lds生成
vmlinux，并通过压缩编程bzImage，或者按要求在对应的子目录下编译成模块。
Linux设备驱动程序设计实例2007-03-03 23:09 Linux系统中，设备驱动程序是操作系统内核的重要组成部分，在与硬件设备之间 建立了标准的抽象接口。通过这个接口，用户可以像处理普通文件一样，对硬件设 备进行打开(open)、关闭(close)、读写(read/write)等操作。通过分析和设计设 备驱动程序，可以深入理解Linux系统和进行系统开发。本文通过一个简单的例子 来说明设备驱动程序的设计。 1、程序清单 //MyDev.c 2000年2月7日编写 #ifndef __KERNEL__ #define __KERNEL__//按内核模块编译 #endif #ifndef MODULE #define MODULE//设备驱动程序模块编译 #endif #define DEVICE_NAME "MyDev" #define OPENSPK 1 #define CLOSESPK 2 //必要的头文件 #include
7.2.3 设备驱动加到Linux内核中 设备驱动程序编写完后将该驱动程序加到内核中。这需要修改Linux 的源代码，然后重新编译内核。 ①将设备驱动程序文件（比如mydriver.c)复制到/Linux/drivers/char目录下。该目录保存了Linux下字符设备的设备驱动程序。修改该目录下mem.c 文件，在int chr_dev_init()函数中增加如下代码： #ifdef CONFIG_MYDRIVER device_init(); #endif 其中CONFIG_MYDRIVER是在配置Linux内核时赋值。 ②在/linux/drivers/char目录下Makefile中增加如下代码： ifeq ($(CONFIG_MYDRIVER),y) L_OBJ + = mydriver.o endif 如果在配置Linux内核时选择了支持新定义的设备，则在编译内核时会编译mydriver.c生成mydriver.o文件。 ③修改/linux/drivers/char目录下config.in文件，在 comment Character devices 语句下面加上 bool suppot for mydriver CONFIG_MYDRIVER 这样，若编译内核，运行make config,make menuconfig或make xconfig,那么在配置字符设备时就会有选项： Support for mydriver 当选中这个设备时，设备驱动就加到了内核中了。 重新编译内核，在shell中将当前目录cd 到Linux目录下，然后执行以下代码： # make menuconfig # make dep # make 在配置选项时要注意选择支持用户添加的设备。这样得到的内核就包含用户的设备驱动程序。 Linux通过设备文件来提供应用程序和设备驱动的接口，应用程序通过标准的文件操作函数来打开、关闭、读取和控制设备。查看Linux文件系统下的/proc/devices,可以看到当前的设备信息。如果设备驱动程序已被成功加进，这里应该由该设备对应的项。/proc/interrupts纪录了当时中断情况，可以用来查看中断申请是否正常；对于DMA和I/O口的使用，在/proc下都有相应的文件进行记录；还可以在设备驱动程序中申请在/proc 文件系统下创建一个文件，该文件用来存放设备相关信息。这样通过查看该文件就可以了解设备的使用情况。总之，/proc文件系统为用户提供了查
实现如下的功能: --字符设备驱动程序的结构及驱动程序需要实现的系统调用 --可以使用cat命令或者自编的readtest命令读出"设备"里的内容 --以8139网卡为例,演示了I/O端口和I/O内存的使用 本文中的大部分内容在Linux Device Driver这本书中都可以找到, 这本书是Linux驱动开发者的唯一圣经。 ================================================== ===== 先来看看整个驱动程序的入口,是char8139_init(这个函数 如果不指定MODULE_LICENSE("GPL", 在模块插入内核的 时候会出错,因为将非"GPL"的模块插入内核就沾污了内核的 "GPL"属性。 module_init(char8139_init; module_exit(char8139_exit; MODULE_LICENSE("GPL"; MODULE_AUTHOR("ypixunil"; MODULE_DESCRIPTION("Wierd char device driver for Realtek 8139 NIC"; 接着往下看char8139_init( static int __init char8139_init(void {
int result; PDBG("hello. init.\n"; /* register our char device */ result=register_chrdev(char8139_major, "char8139", &char8139_fops; if(result<0 { PDBG("Cannot allocate major device number!\n"; return result; } /* register_chrdev( will assign a major device number and return if it called * with "major" parameter set to 0 */ if(char8139_major == 0 char8139_major=result; /* allocate some kernel memory we need */ buffer=(unsigned char*(kmalloc(CHAR8139_BUFFER_SIZE, GFP_KERNEL; if(!buffer { PDBG("Cannot allocate memory!\n"; result= -ENOMEM;
Linux内核驱动加载顺序 【问题】 背光驱动初始化先于LCD驱动初始化，导致LCD驱动初始化时出现闪屏的现象。 【解决过程】 1 mach-xxx.c中platform devices列表如下 /* platform devices */ static struct platform_device *athena_evt_platform_devices[] __initdata = { //&xxx_led_device, &xxx_rtc_device, &xxx_uart0_device, &xxx_uart1_device, &xxx_uart2_device, &xxx_uart3_device, &xxx_nand_device, &xxx_i2c_device, &xxx_lcd_device, &xxxpwm_backlight_device, ... }; LCD（xxx_lcd_device）设备先于PWM（xxxpwm_backlight_device）设备。 可见驱动的初始化顺序并不是和这个表定义的顺序始终保持一致的。（记得PM操作 - resume/suspend 的顺序 是和这个表的顺序保持一致的） 2 怀疑和编译顺序有关 Z:\kernel\drivers\video\Makefile：背光驱动（backlight/)的编译限于LCD驱动（xxxfb.o）的编译 obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-y += backlight/ display/ ... obj-$(CONFIG_FB_xxx) += xxxfb.o ak_logo.o obj-$(CONFIG_FB_AK88) += ak88-fb/ 这样编译生成的System.map中的顺序为： 906 c001f540 t __initcall_pwm_backlight_init6 907 c001f544 t __initcall_display_class_init6 908 c001f548 t __initcall_xxxfb_init6 Makefile更改为： obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-y += display/
Linux设备驱动程序学习（18）－USB 驱动程序（三） (2009-07-14 11:45) 分类：Linux设备驱动程序 USB urb （USB request block） 内核使用2.6.29.4 USB 设备驱动代码通过urb和所有的 USB 设备通讯。urb用 struct urb 结构描述（include/linux/usb.h ）。 urb以一种异步的方式同一个特定USB设备的特定端点发送或接受数据。一个USB 设备驱动可根据驱动的需要，分配多个 urb 给一个端点或重用单个 urb 给多个不同的端点。设备中的每个端点都处理一个 urb 队列, 所以多个 urb 可在队列清空之前被发送到相同的端点。 一个 urb 的典型生命循环如下: （1）被创建； （2）被分配给一个特定 USB 设备的特定端点； （3）被提交给 USB 核心； （4）被 USB 核心提交给特定设备的特定 USB 主机控制器驱动； （5）被 USB 主机控制器驱动处理, 并传送到设备； （6）以上操作完成后，USB主机控制器驱动通知 USB 设备驱动。 urb 也可被提交它的驱动在任何时间取消；如果设备被移除，urb 可以被USB 核心取消。urb 被动态创建并包含一个内部引用计数，使它们可以在最后一个用户释放它们时被自动释放。 struct urb
struct list_head urb_list;/* list head for use by the urb's * current owner */ struct list_head anchor_list;/* the URB may be anchored */ struct usb_anchor *anchor; struct usb_device *dev;/* 指向这个 urb 要发送的目标 struct usb_device 的指针,这个变量必须在这个 urb 被发送到 USB 核心之前被USB 驱动初始化.*/ struct usb_host_endpoint *ep;/* (internal) pointer to endpoint */ unsigned int pipe;/* 这个 urb 所要发送到的特定struct usb_device 的端点消息,这个变量必须在这个 urb 被发送到 USB 核心之前被 USB 驱动初始化.必须由下面的函数生成*/ int status;/*当 urb开始由 USB 核心处理或处理结束, 这个变量被设置为 urb 的当前状态. USB 驱动可安全访问这个变量的唯一时间是在 urb 结束处理例程函数中. 这个限制是为防止竞态. 对于等时 urb, 在这个变量中成功值(0)只表示这个 urb 是否已被去链. 为获得等时 urb 的详细状态, 应当检查 iso_frame_desc 变量. */ unsigned int transfer_flags;/* 传输设置*/ void*transfer_buffer;/* 指向用于发送数据到设备(OUT urb)或者从设备接收数据(IN urb)的缓冲区指针。为了主机控制器驱动正确访问这个缓冲, 它必须使用 kmalloc 调用来创建, 不是在堆栈或者静态内存中。对控制端点, 这个缓冲区用于数据中转*/ dma_addr_t transfer_dma;/* 用于以 DMA 方式传送数据到 USB 设备的缓冲区*/ int transfer_buffer_length;/* transfer_buffer 或者 transfer_dma 变量指向的缓冲区大小。如果这是 0, 传送缓冲没有被 USB 核心所使用。对于一个 OUT 端点, 如果这个端点大小比这个变量指定的值小, 对这个USB 设备的传输将被分成更小的块，以正确地传送数据。这种大的传送以连续的 USB 帧进行。在一个 urb 中提交一个大块数据, 并且使 USB 主机控制器去划分为更小的块, 比以连续地顺序发送小缓冲的速度快得多*/
Linux2.6设备驱动常用的接口函数（一） ----字符设备 刚开始，学习linux驱动，觉得linux驱动很难，有字符设备，块设备，网络设备，针对每一种设备其接口函数，驱动的架构都不一样。这么多函数，要每一个的熟悉，那可多难啦！可后来发现linux驱动有很多规律可循，驱动的基本框架都差不多，再就是一些通用的模块。 基本的架构里包括：加载，卸载，常用的读写，打开，关闭，这是那种那基本的咯。利用这些基本的功能，当然无法实现一个系统。比方说：当多个执行单元对资源进行访问时，会引发竞态；当执行单元获取不到资源时，它是阻塞还是非阻塞？当突然间来了中断，该怎么办？还有内存管理，异步通知。而linux 针对这些问题提供了一系列的接口函数和模板框架。这样，在实际驱动设计中，根据具体的要求，选择不同的模块来实现其功能需求。 觉得能熟练理解，运用这些函数，是写号linux设备驱动的第一步。因为是设备驱动，是与最底层的设备打交道，就必须要熟悉底层设备的一些特性，例如字符设备，块设备等。系统提供的接口函数，功能模块就像是工具，能够根据不同的底层设备的的一些特性，选择不同的工具，方能在linux驱动中游刃有余。 最后就是调试，这可是最头疼的事。在调试过程中，总会遇到这样，那样的问题。怎样能更快，更好的发现并解决这些问题，就是一个人的道行咯！我个人觉得： 发现问题比解决问题更难！ 时好时坏的东西，最纠结！ 看得见的错误比看不见的错误好解决！ 一：Fops结构体中函数： ①ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); 用来从设备中获取数据. 在这个位置的一个空指针导致 read 系统调用以-EINVAL("Invalid argument") 失败. 一个非负返回值代表了成功读取的字节数( 返回值是一个 "signed size" 类型, 常常是目标平台本地的整数类型). ②ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); 发送数据给设备. 如果 NULL, -EINVAL 返回给调用 write 系统调用的程序. 如果非负, 返回值代表成功写的字节数 ③loff_t (*llseek) (struct file *, loff_t, int); llseek 方法用作改变文件中的当前读/写位置, 并且新位置作为(正的)返回值. loff_t 参数是一个"long offset", 并且就算在 32位平台上也至少 64 位宽. 错误由一个负返回值指示. 如果这个函数指针是 NULL, seek 调用会以潜在地无法预知的方式修改 file 结构中的位置计数器( 在"file 结构" 一节中描述). ④int (*open) (struct inode *, struct file *);
对于每一个配置选项，用户可以回答"y"、"m"或"n"。其中"y"表示将相应特性的支持或设备驱动程序编译进内核；"m"表示将相应特性的支持或设备驱动程序编译成可加载模块，在需要时，可由系统或用户自行加入到内核中去；"n"表示内核不提供相应特性或驱动程序的支持。只有<>才能选择M 1. General setup（通用选项） [*]Prompt for development and/or incomplete code/drivers，设置界面中显示还在开发或者还没有完成的代码与驱动，最好选上，许多设备都需要它才能配置。 [ ]Cross-compiler tool prefix，交叉编译工具前缀，如果你要使用交叉编译工具的话输入相关前缀。默认不使用。嵌入式linux更不需要。 [ ]Local version - append to kernel release，自定义版本，也就是uname -r可以看到的版本，可以自行修改，没多大意义。 [ ]Automatically append version information to the version string，自动生成版本信息。这个选项会自动探测你的内核并且生成相应的版本，使之不会和原先的重复。这需要Perl的支持。由于在编译的命令make-kpkg 中我们会加入- –append-to-version 选项来生成自定义版本，所以这里选N。 Kernel compression mode (LZMA)，选择压缩方式。 [ ]Support for paging of anonymous memory (swap)，交换分区支持，也就是虚拟内存支持，嵌入式不需要。 [*]System V IPC，为进程提供通信机制，这将使系统中各进程间有交换信息与保持同步的能力。有些程序只有在选Y的情况下才能运行，所以不用考虑，这里一定要选。 [*]POSIX Message Queues，这是POSIX的消息队列，它同样是一种IPC(进程间通讯)。建议你最好将它选上。 [*]BSD Process Accounting，允许进程访问内核，将账户信息写入文件中，主要包括进程的创建时间/创建者/内存占用等信息。可以选上，无所谓。 [*]BSD Process Accounting version 3 file format，选用的话统计信息将会以新的格式（V3）写入，注意这个格式和以前的v0/v1/v2 格式不兼容，选不选无所谓。 [ ]Export task/process statistics through netlink (EXPERIMENTAL)，通过通用的网络输出工作/进程的相应数据，和BSD不同的是，这些数据在进程运行的时候就可以通过相关命令访问。和BSD类似，数据将在进程结束时送入用户空间。如果不清楚，选N（实验阶段功能，下同）。 [ ]Auditing support，审计功能，某些内核模块需要它（SELINUX），如果不知道，不用选。 [ ]RCU Subsystem，一个高性能的锁机制RCU 子系统，不懂不了解，按默认就行。 [ ]Kernel .config support，将.config配置信息保存在内核中，选上它及它的子项使得其它用户能从/proc/ config.gz中得到内核的配置,选上，重新配置内核时可以利用已有配置Enable access to .config through /proc/config.gz，上一项的子项，可以通过/proc/ config.gz访问.config配置，上一个选的话，建议选上。 (16)Kernel log buffer size (16 => 64KB, 17 => 128KB) ，内核日志缓存的大小，使用默认值即可。12 => 4 KB，13 => 8 KB，14 => 16 KB单处理器，15 => 32 KB多处理器，16 => 64 KB，17 => 128 KB。 [ ]Control Group support（有子项），使用默认即可，不清楚可以不选。 Example debug cgroup subsystem，cgroup子系统调试例子 Namespace cgroup subsystem，cgroup子系统命名空间 Device controller for cgroups，cgroups设备控制器
以下电子书来源于宋宝华《Linux设备驱动开发详解：基于最新的Linux 4.0内核》第19章《Linux电源管理系统架构和驱动》 本章导读 Linux在消费电子领域的应用已经铺天盖地，而对于消费电子产品而言，省电是一个重要的议题。 本章将介绍Linux设备树（Device Tree）的起源、结构和因为设备树而引起的驱动和BSP 变更。 19.1节阐述了Linux电源管理的总体架构。 19.2~19.8节分别论述了CPUFreq、CPUIdle、CPU热插拔以及底层的基础设施Regulator、OPP以及电源管理的调试工具PowerTop。 19.9节讲解了系统Suspend to RAM的过程以及设备驱动如何提供对Suspend to RAM的支持。 19.10节讲解了设备驱动的Runtime suspend。 本章是相对《Linux设备驱动开发详解（第2版）》全新的一章内容，也是Linux设备驱动工程师必备的知识体系。
第十九章Linux电源管理系统架构和驱动 1.Linux电源管理全局架构 Linux电源管理非常复杂，牵扯到系统级的待机、频率电压变换、系统空闲时的处理以及每个设备驱动对于系统待机的支持和每个设备的运行时电源管理，可以说和系统中的每个设备驱动都息息相关。 对于消费电子产品来说，电源管理相当重要。因此，这部分工作往往在开发周期中占据相当大的比重，图19.1呈现了Linux内核电源管理的整体架构。大体可以归纳为如下几类： 1.CPU在运行时根据系统负载进行动态电压和频率变换的CPUFreq 2.CPU在系统空闲时根据空闲的情况进行低功耗模式的CPUIdle 3.多核系统下CPU的热插拔支持 4.系统和设备对于延迟的特别需求而提出申请的PM QoS，它会作用于CPUIdle的具体 策略 5.设备驱动针对系统Suspend to RAM/Disk的一系列入口函数 6.SoC进入suspend状态、SDRAM自刷新的入口 7.设备的runtime（运行时）动态电源管理，根据使用情况动态开关设备 8.底层的时钟、稳压器、频率/电压表（OPP模块完成）支撑，各驱动子系统都可能用 到 图19.1 Linux电源管理系统架构 2.CPUFreq驱动 CPUFreq子系统位于drivers/cpufreq目录，负责进行运行过程中CPU频率和电压的动态
如果你对内核驱动模块一无所知，请先学习内核驱动模块的基础知识。 如果你已经入门了内核驱动模块，但是仍感觉有些模糊，不能从整体来了解一个内核驱动模块的结构，请赏读一下这篇拙文。 如果你已经从事内核模块编程N年，并且道行高深，也请不吝赐教一下文中的疏漏错误。 本文中我将实现一个简单的Linux字符设备，旨在大致勾勒出linux内核模块的编写方法的轮廓。其中重点介绍ioctl的用途。 我把这个简单的Linux字符设备模块命名为hello_mod. 设备类型名为hello_cl ass 设备名为hello 该设备是一个虚拟设备，模块加载时会在/sys/class/中创建名为hello_class 的逻辑设备，在/dev/中创建hello的物理设备文件。模块名为hello_mod，可接受输入字符串数据（长度小于128），处理该输入字符串之后可向外输出字符串。并且可以接受ioctl（）函数控制内部处理字符串的方式。 例如： a.通过write函数写入“Tom”，通过ioctl函数设置langtype=chinese，通过read函数读出的数据将会是“你好！Tom/n” b.通过write函数写入“Tom”，通过ioctl函数设置langtype=english，通过read函数读出的数据将会是“hello！Tom/n” c.通过write函数写入“Tom”，通过ioctl函数设置langtype=pinyin，通过read函数读出的数据将会是“ni hao！Tom/n” 一般的内核模块中不会负责设备类别和节点的创建，我们在编译完之后会得到.o或者.k o文件，然后insmod之后需要mk nod来创建相应文件，这个简单的例子 中我们让驱动模块加载时负责自动创建设备类别和设备文件。这个功能有两个步骤， 1）创建设备类别文件class_cr eate(); 2）创建设备文件dev ice_create(); 关于这两个函数的使用方法请参阅其他资料。 linux设备驱动的编写相对wi ndows编程来说更容易理解一点因为不需要处理IR P，应用层函数和内核函数的关联方式浅显易懂。 比如当应曾函数对我的设备调用了open()函数，而最终这个应用层函数会调用我的设备中的自定义open()函数，这个函数要怎么写呢， 我在我的设备中定义的函数名是hello_mod_open，注意函数名是可以随意定义，但是函数签名是要符合内核要求的，具体的定义是怎么样请看
Linux设备驱动程序学习（20）-内存映射和DMA-基本概念 (2011-09-25 15:47) 标签: 虚拟内存设备驱动程序Linux技术分类：Linux设备驱动程序 这部分主要研究 Linux 内存管理的基础知识, 重点在于对设备驱动有用的技术. 因为许多驱动编程需要一些对于虚拟内存（VM）子系统原理的理解。 而这些知识主要分为三个部分： 1、 mmap系统调用的实现原理：它允许设备内存直接映射到一个用户进程地址 空间. 这样做对一些设备来说可显著地提高性能. 2、与mmap的功能相反的应用原理：内核态代码如何跨过边界直接存取用户空间的内存页. 虽然较少驱动需要这个能力. 但是了解如何映射用户空间内存到内 核(使用 get_user_pages)会有用. 3、直接内存存取( DMA ) I/O 操作, 它提供给外设对系统内存的直接存取. 但所有这些技术需要理解 Linux 内存管理的基本原理, 因此我将先学习VM子 系统的基本原理. 一、Linux的内存管理 这里重点是 Linux 内存管理实现的主要特点，而不是描述操作系统的内存管理理论。Linux虚拟内存管理非常的复杂，要写可以写一本书：《深入理解Linux 虚拟内存管理》。学习驱动无须如此深入, 但是对它的工作原理的基本了解是必要的. 解了必要的背景知识后,才可以学习内核管理内存的数据结构. Linux是一个虚拟内存系统（但是在没有MMU的CPU中跑的ucLinux除外）, 意味着在内核启动了MMU 之后所有使用的地址不直接对应于硬件使用的物理地址，这些地址（称之为虚拟地址）都经过了MMU转换为物理地址之后再从CPU的内存总线中发出，读取/写入数据. 这样 VM 就引入了一个间接层, 它是许多操作成为可能： 1、系统中运行的程序可以分配远多于物理内存的内存空间，即便单个进程都可拥有一个大于系统的物理内存的虚拟地址空间. 2、虚拟内存也允许程序对进程的地址空间运用多种技巧, 包括映射程序的内存到设备内存.等等～～～ 1、地址类型 Linux 系统处理几种类型的地址, 每个有它自己的含义： 用户虚拟地址：User virtual addresses，用户程序见到的常规地址. 用户地址在长度上是 32 位或者 64 位, 依赖底层的硬件结构, 并且每个进程有它自己 的虚拟地址空间.
参考： 韦东山视频第10课第一节内核启动流程分析之编译体验 第11课第三节构建根文件系统之busybox 第11课第四节构建根文件系统之构建根文件系统韦东山书籍《嵌入式linux应用开发完全手册》 其他《linux设备驱动程序》第三版 平台： JZ2440、mini2440或TQ2440 交叉网线和miniUSB PC机（windows系统和Vmware下的ubuntu12.04） 一、交叉编译环境的选型 具体的安装交叉编译工具，网上很多资料都有，我的那篇《arm-linux- gcc交叉环境相关知识》也有介绍，这里我只是想提示大家：构建跟文件系统中所用到的lib库一定要是本系统Ubuntu中的交叉编译环境arm-linux- gcc中的。即如果电脑ubuntu中的交叉编译环境为arm-linux-
二、主机、开发板和虚拟机要三者互通 w IP v2.0》一文中有详细的操作步骤，不再赘述。 linux 2.6.22.6_jz2440.patch组合而来，具体操作： 1. 解压缩内核和其补丁包 tar xjvf linux-2.6.22.6.tar.bz2 # 解压内核 tar xjvf linux-2.6.22.6_jz2440.tar.bz2 # 解压补丁
cd linux_2.6.22.6 patch –p1 < ../linux-2.6.22.6_jz2440.patch 3. 配置 在内核目录下执行make 2410_defconfig生成配置菜单，至于怎么配置，《嵌入式linux应用开发完全手册》有详细介绍。 4. 生成uImage make uImage 四、移植busybox 在我们的根文件系统中的/bin和/sbin目录下有各种命令的应用程序，而这些程序在嵌入式系统中都是通过busybox来构建的，每一个命令实际上都是一个指向bu sybox的链接,busybox通过传入的参数来决定进行何种命令操作。 1）配置busybox 解压busybox-1.7.0,然后进入该目录，使用make menuconfig进行配置。这里我们这配置两项 一是在编译选项选择动态库编译，当然你也可以选择静态，不过那样构建的根文件系统会比动态编译的的大。 ->Busybox Settings ->Build Options
本讲主要概述Linux设备驱动框架、驱动程序的配置文件及常用的加载驱动程序的方法；并且介绍Red Hat Linux安装程序是如何加载驱动的，通过了解这个过程，我们可以自己将驱动程序放到引导盘中；安装完系统后，使用kudzu自动配置硬件程序。 Linux设备驱动概述 1. 内核和驱动模块 操作系统是通过各种驱动程序来驾驭硬件设备，它为用户屏蔽了各种各样的设备，驱动硬件是操作系统最基本的功能，并且提供统一的操作方式。正如我们查看屏幕上的文档时,不用去管到底使用nVIDIA芯片，还是ATI芯片的显示卡，只需知道输入命令后，需要的文字就显示在屏幕上。硬件驱动程序是操作系统最基本的组成部分，在Linux内核源程序中也占有较高的比例。 Linux内核中采用可加载的模块化设计（LKMs ，Loadable Kernel Modules），一般情况下编译的Linux内核是支持可插入式模块的，也就是将最基本的核心代码编译在内核中，其它的代码可以选择是在内核中，或者编译为内核的模块文件。 如果需要某种功能，比如需要访问一个NTFS分区，就加载相应的NTFS模块。这种设计可以使内核文件不至于太大，但是又可以支持很多的功能，必要时动态地加载。这是一种跟微内核设计不太一样，但却是切实可行的内核设计方案。 我们常见的驱动程序就是作为内核模块动态加载的，比如声卡驱动和网卡驱动等，而Linux最基础的驱动，如CPU、PCI总线、TCP/IP协议、APM（高级电源管理）、VFS等驱动程序则编译在内核文件中。有时也把内核模块就叫做驱动程序，只不过驱动的内容不一定是硬件罢了，比如ext3文件系统的驱动。 理解这一点很重要。因此，加载驱动时就是加载内核模块。下面来看一下有关模块的命令，在加载驱动程序要用到它们：lsmod、modprob、insmod、rmmod、modinfo。 lsmod
第一章Linux设备驱动程序简介 Linux Kernel 系统架构图 一、驱动程序的特点 ?是应用和硬件设备之间的一个软件层。 ?这个软件层一般在内核中实现 ?设备驱动程序的作用在于提供机制，而不是提供策略，编写访问硬件的内核代码时不要给用户强加任何策略 o机制：驱动程序能实现什么功能。 o策略：用户如何使用这些功能。 二、设备驱动分类和内核模块 ?设备驱动类型。Linux 系统将设备驱动分成三种类型 o字符设备 o块设备 o网络设备 ?内核模块：内核模块是内核提供的一种可以动态加载功能单元来扩展内核功能的机制，类似于软件中的插件机制。这种功能单元叫内核模块。 ?通常为每个驱动创建一个不同的模块，而不在一个模块中实现多个设备驱动，从而实现良好的伸缩性和扩展性。 三、字符设备 ?字符设备是个能够象字节流<比如文件）一样访问的设备，由字符设备驱动程序来实现这种特性。通过/dev下的字符设备文件来访问。字符设备驱动程序通常至少需要实现 open、close、read 和 write 等系统调用 所对应的对该硬件进行操作的功能函数。 ?应用程序调用system call<系统调用），例如：read、write，将会导致操作系统执行上层功能组件的代码，这些代码会处理内核的一些内部 事务，为操作硬件做好准备，然后就会调用驱动程序中实现的对硬件进 行物理操作的函数，从而完成对硬件的驱动，然后返回操作系统上层功 能组件的代码，做好内核内部的善后事务，最后返回应用程序。 ?由于应用程序必须使用/dev目录下的设备文件<参见open调用的第1个参数），所以该设备文件必须事先创建。谁创建设备文件呢？ ?大多数字符设备是个只能顺序访问的数据通道，不能前后移动访问指针，这点和文件不同。比如串口驱动，只能顺序的读写设备。然而，也 存在和数据区或者文件特性类似的字符设备，访问它们时可前后移动访
ARM-uClinux下编写加载驱动程序详细过程 本文主要介绍在uClinux下，通过加载模块的方式调试IO控制蜂鸣器的驱动程序。实验过程与上篇文章所讲的过程基本相似，更多注重细节及注意事项。 本文适合学习ARM—Linux的初学者。 //================================================================== 硬件平台：MagicARM2200教学试验开发平台（LPC2290） Linux version 2.4.24，gcc version 2.95.3 电路连接：P0.7——蜂鸣器，低电平发声。 实验条件：uClinux内核已经下载到开发板上，能够正常运行；与宿主机相连的网络、串口连接正常。 //================================================================== 编写蜂鸣器的驱动程序相对来说容易实现，不需要处理中断等繁琐的过程，本文以蜂鸣器的驱动程序为例，详细说明模块化驱动程序设计的主要过程和注意事项。 一、编写驱动程序 驱动程序的编写与上文所说的编写过程基本相同，这里再详细说明一下。 //========================================== //蜂鸣器驱动程序：beep.c文件 //------------------------------------------------------------------- #include
文库资料?2017 Guangzhou ZHIYUAN Electronics Stock Co., Ltd. 如何实现Linux 设备驱动模型 设备驱动模型，对系统的所有设备和驱动进行了抽象，形成了复杂的设备树型结构，采用面向对象的方法，抽象出了device 设备、driver 驱动、bus 总线和class 类等概念，所有已经注册的设备和驱动都挂在总线上，总线来完成设备和驱动之间的匹配。总线、设备、驱动以及类之间的关系错综复杂，在Linux 内核中通过kobject 、kset 和subsys 来进行管理，驱动编写可以忽略这些管理机制的具体实现。 设备驱动模型的内部结构还在不停的发生改变，如device 、driver 、bus 等数据结构在不同版本都有差异，但是基于设备驱动模型编程的结构基本还是统一的。 Linux 设备驱动模型是Linux 驱动编程的高级内容，这一节只对device 、driver 等这些基本概念作介绍，便于阅读和理解内核中的代码。实际上，具体驱动也不会孤立的使用这些概念，这些概念都融合在更高层的驱动子系统中。对于大多数读者可以忽略这一节内容。 1.1.1 设备 在Linux 设备驱动模型中，底层用device 结构来描述所管理的设备。device 结构在文件
网址https://www.doczj.com/doc/7914207337.html,/thread-1950216-1-1.html 如何调整Linux内核启动中的驱动初始化顺序 【问题】 此处我要实现的是将芯片的ID用于网卡MAC地址，网卡驱动是enc28j60_init。 但是，读取芯片ID的函数，在as352x_afe_init模块中，所以要先初始化as352x_afe_init。此处，内核编译完之后，在生成的system.map中可以看到， enc28j60_init在as352x_afe_init之前，所以，无法去读芯片ID。 所以我们的目标是，将as352x_afe_init驱动初始化放到enc28j60_init之前， 然后才能读取芯片ID，才能用于网卡初始化的时候的，将芯片ID设置成网卡MAC地址。 【解决过程】 【1】 最简单想到的，是内核里面的 arch\arm\mach-as352x\core.c 中，去改devices设备列表中的顺序。 enc28j60_init对应的是ssp_device，因为网卡初始化用到的是SPI驱动去进行和通讯的。as352x_afe_init对应的是afe_device。 原先是： static struct platform_device *devices[] = { &uart_device, &nand_device, &afe_device, &audio_device, &usb_device, &as352xkbd_device, &ssp_device, }; 复制代码 把afe改到最前面： static struct platform_device *devices[] = { &afe_device, &uart_device, &nand_device, &audio_device, &usb_device, &as352xkbd_device, &ssp_device, }; 复制代码