linux设备驱动层

❶ linux设备驱动程序如何与硬件通信

LINUX设备驱动程序是怎么样和硬件通信的?下面将由我带大家来解答这个疑问吧，希望对大家有所收获!

LINUX设备驱动程序与硬件设备之间的通信

设备驱动程序是软件概念和硬件电路之间的一个抽象层，因此两方面都要讨论。到目前为止，我们已经讨论详细讨论了软件概念上的一些细节，现在讨论另一方面，介绍驱动程序在Linux上如何在保持可移植性的前提下访问I/O端口和I/O内存。

我们在需要示例的场合会使用简单的数字I/O端口来讲解I/O指令，并使用普通的帧缓冲区显存来讲解内存映射I/O。

I/O端口和I/O内存

计算机对每种外设都是通过读写它的寄存器进行控制的。大部分外设都有几个寄存器，不管是在内存地址空间还是在I/O地址空间，这些寄存器的访问地址都是连续的。

I/O端口就是I/O端口，设备会把寄存器映射到I/O端口，不管处理器是否具有独立的I/O端口地址空间。即使没有在访问外设时也要模拟成读写I/O端口。

I/O内存是设备把寄存器映射到某个内存地址区段(如PCI设备)。这种I/O内存通常是首先方案，它不需要特殊的处理器指令，而且CPU核心访问内存更有效率。

I/O寄存器和常规内存

尽管硬件寄存器和内存非常相似，但程序员在访问I/O寄存器的时候必须注意避免由于CPU或编译器不恰当的优化而改变预期的I/O动作。

I/O寄存器和RAM最主要的区别就是I/O操作具有边际效应，而内存操作则没有：由于内存没有边际效应，所以可以用多种 方法 进行优化，如使用高速缓存保存数值、重新排序读/写指令等。

编译器能够将数值缓存在CPU寄存器中而不写入内存，即使储存数据，读写操作也都能在高速缓存中进行而不用访问物理RAM。无论是在编译器一级或是硬件一级，指令的重新排序都有可能发生：一个指令序列如果以不同于程序文本中的次序运行常常能执行得更快。

在对常规内存进行这些优化的时候，优化过程是透明的，而且效果良好，但是对I/O操作来说这些优化很可能造成致命的错误，这是因为受到边际效应的干扰，而这却是驱动程序访问I/O寄存器的主要目的。处理器无法预料某些 其它 进程(在另一个处理器上运行，或在在某个I/O控制器中发生的操作)是否会依赖于内存访问的顺序。编译器或CPU可能会自作聪明地重新排序所要求的操作，结果会发生奇怪的错误，并且很难调度。因此，驱动程序必须确保不使用高速缓冲，并且在访问寄存器时不发生读或写指令的重新排序。

由硬件自身引起的问题很解决：只要把底层硬件配置成(可以是自动的或是由Linux初始化代码完成)在访问I/O区域(不管是内存还是端口)时禁止硬件缓存即可。

由编译器优化和硬件重新排序引起的问题的解决办法是：对硬件(或其他处理器)必须以特定顺序的操作之间设置内存屏障(memory barrier)。Linux提供了4个宏来解决所有可能的排序问题：

#include <linux/kernel.h>

void barrier(void)

这个函数通知编译器插入一个内存屏障，但对硬件没有影响。编译后的代码会把当前CPU寄存器中的所有修改过的数值保存到内存中，需要这些数据的时候再重新读出来。对barrier的调用可避免在屏障前后的编译器优化，但硬件完成自己的重新排序。

#include <asm/system.h>

void rmb(void);

void read_barrier_depends(void);

void wmb(void);

void mb(void);

这些函数在已编译的指令流中插入硬件内存屏障;具体实现方法是平台相关的。rmb(读内存屏障)保证了屏障之前的读操作一定会在后来的读操作之前完成。wmb保证写操作不会乱序，mb指令保证了两者都不会。这些函数都是barrier的超集。

void smp_rmb(void);

void smp_read_barrier_depends(void);

void smp_wmb(void);

void smp_mb(void);

上述屏障宏版本也插入硬件屏障，但仅仅在内核针对SMP系统编译时有效;在单处理器系统上，它们均会被扩展为上面那些简单的屏障调用。

设备驱动程序中使用内存屏障的典型形式如下：

writel(dev->registers.addr, io_destination_address);

writel(dev->registers.size, io_size);

writel(dev->registers.operation, DEV_READ);

wmb();

writel(dev->registers.control, DEV_GO);

在这个例子中，最重要的是要确保控制某种特定操作的所有设备寄存器一定要在操作开始之前已被正确设置。其中的内存屏障会强制写操作以要求的顺序完成。

因为内存屏障会影响系统性能，所以应该只用于真正需要的地方。不同类型的内存屏障对性能的影响也不尽相同，所以最好尽可能使用最符合需要的特定类型。

值得注意的是，大多数处理同步的内核原语，如自旋锁和atomic_t操作，也能作为内存屏障使用。同时还需要注意，某些外设总线(比如PCI总线)存在自身的高速缓存问题，我们将在后面的章节中讨论相关问题。

在某些体系架构上，允许把赋值语句和内存屏障进行合并以提高效率。内核提供了几个执行这种合并的宏，在默认情况下，这些宏的定义如下：

#define set_mb(var, value) do {var = value; mb();} while 0

#define set_wmb(var, value) do {var = value; wmb();} while 0

#define set_rmb(var, value) do {var = value; rmb();} while 0

在适当的地方，<asm/system.h>中定义的这些宏可以利用体系架构特有的指令更快的完成任务。注意只有小部分体系架构定义了set_rmb宏。

使用I/O端口

I/O端口是驱动程序与许多设备之间的通信方式——至少在部分时间是这样。本节讲解了使用I/O端口的不同函数，另外也涉及到一些可移植性问题。

I/O端口分配

下面我们提供了一个注册的接口，它允允许驱动程序声明自己需要操作的端口：

#include <linux/ioport.h>

struct resource *request_region(unsigned long first, unsigned long n, const char *name);

它告诉内核，我们要使用起始于first的n个端口。name是设备的名称。如果分配成功返回非NULL，如果失败返回NULL。

所有分配的端口可从/proc/ioports中找到。如果我们无法分配到我们要的端口集合，则可以查看这个文件哪个驱动程序已经分配了这些端口。

如果不再使用这些端口，则用下面函数返回这些端口给系统：

void release_region(unsigned long start, unsigned long n);

下面函数允许驱动程序检查给定的I/O端口是否可用：

int check_region(unsigned long first, unsigned long n);//不可用返回负的错误代码

我们不赞成用这个函数，因为它返回成功并不能确保分配能够成功，因为检查和其后的分配并不是原子操作。我们应该始终使用request_region，因为这个函数执行了必要的锁定，以确保分配过程以安全原子的方式完成。

操作I/O端口

当驱动程序请求了需要使用的I/O端口范围后，必须读取和/或写入这些端口。为此，大多数硬件都会把8位、16位、32位区分开来。它们不能像访问系统内存那样混淆使用。

因此，C语言程序必须调用不同的函数访问大小不同的端口。那些只支持映射的I/O寄存器的计算机体系架构通过把I/O端口地址重新映射到内存地址来伪装端口I/O，并且为了易于移植，内核对驱动程序隐藏了这些细节。Linux内核头文件中(在与体系架构相关的头文件<asm/io.h>中)定义了如下一些访问I/O端口的内联函数：

unsigned inb(unsigned port);

void outb(unsigned char byte, unsigned port);

字节读写端口。

unsigned inw(unsigned port);

void outw(unsigned short word, unsigned port);

访问16位端口

unsigned inl(unsigned port);

void outl(unsigned longword, unsigned port);

访问32位端口

在用户空间访问I/O端口

上面这些函数主要是提供给设备驱动程序使用的，但它们也可以用户空间使用，至少在PC类计算机上可以使用。GNU的C库在<sys/io.h>中定义了这些函数。如果要要用户空间使用inb及相关函数，则必须满足正下面这些条件：

编译程序时必须带有-O选项来强制内联函数的展开。

必须用ioperm(获取单个端口的权限)或iopl(获取整个I/O空间)系统调用来获取对端口进行I/O操作的权限。这两个函数都是x86平台特有的。

必须以root身份运行该程序才能调用ioperm或iopl。或者进程的祖先进程之一已经以root身份获取对端口的访问。

如果宿主平台没有以上两个系统调用，则用户空间程序仍然可以使用/dev/port设备文件访问I/O端口。不过要注意，该设备文件的含义与平台密切相关，并且除PC平台以处，它几乎没有什么用处。

串操作

以上的I/O操作都是一次传输一个数据，作为补充，有些处理器实现了一次传输一个数据序列的特殊指令，序列中的数据单位可以是字节、字、双字。这些指令称为串操作指令，它们执行这些任务时比一个C语言编写的循环语句快得多。下面列出的宏实现了串I/O：

void insb(unsigned port, void *addr, unsigned long count);

void outsb(unsigned port, void *addr, unsigned long count);从内存addr开始连续读/写count数目的字节。只对单一端口port读取或写入数据

void insw(unsigned port, void *addr, unsigned long count);

void outsw(unsigned port, void *addr, unsigned long count);对一个16位端口读写16位数据

void insl(unsigned port, void *addr, unsigned long count);

void outsl(unsigned port, void *addr, unsigned long count);对一个32位端口读写32位数据

在使用串I/O操作函数时，需要铭记的是：它们直接将字节流从端口中读取或写入。因此，当端口和主机系统具有不同的字节序时，将导致不可预期的结果。使用inw读取端口将在必要时交换字节，以便确保读入的值匹配于主机的字节序。然而，串函数不会完成这种交换。

暂停式I/O

在处理器试图从总线上快速传输数据时，某些平台(特别是i386)就会出现问题。当处理器时钟比外设时钟(如ISA)快时就会出现问题，并且在设备板上特别慢时表现出来。为了防止出现丢失数据的情况，可以使用暂停式的I/O函数来取代通常的I/O函数，这些暂停式的I/O函数很像前面介绍的那些I/O函数，不同之处是它们的名字用_p结尾，如inb_p、outb_p等等。在linux支持的大多数平台上都定义了这些函数，不过它们常常扩展为非暂停式I/O同样的代码，因为如果不使用过时的外设总线就不需要额外的暂停。

平台相关性

I/O指令是与处理器密切相关的。因为它们的工作涉及到处理器移入移出数据的细节，所以隐藏平台间的差异非常困难。因此，大部分与I/O端口相关的源代码都与平台相关。

回顾前面函数列表可以看到有一处不兼容的地方，即数据类型。函数的参数根据各平台体系架构上的不同要相应地使用不同的数据类型。例如，port参数在x86平台上(处理器只支持64KB的I/O空间)上定义为unsigned short，但在其他平台上定义为unsigned long，在这些平台上，端口是与内存在同一地址空间内的一些特定区域。

感兴趣的读者可以从io.h文件获得更多信息，除了本章介绍的函数，一些与体系架构相关的函数有时也由该文件定义。

值得注意的是，x86家族之外的处理器都不为端口提供独立的地址空间。

I/O操作在各个平台上执行的细节在对应平台的编程手册中有详细的叙述;也可以从web上下载这些手册的PDF文件。

I/O端口示例

演示设备驱动程序的端口I/O的示例代码运行于通用的数字I/O端口上，这种端口在大多数计算机平台上都能找到。

数字I/O端口最常见的一种形式是一个字节宽度的I/O区域，它或者映射到内存，或者映射到端口。当把数字写入到输出区域时，输出引脚上的电平信号随着写入的各位而发生相应变化。从输入区域读取到的数据则是输入引脚各位当前的逻辑电平值。

这类I/O端口的具体实现和软件接口是因系统而异的。大多数情况下，I/O引脚由两个I/O区域控制的：一个区域中可以选择用于输入和输出的引脚，另一个区域中可以读写实际的逻辑电平。不过有时情况简单些，每个位不是输入就是输出(不过这种情况下就不能称为“通用I/O"了);在所有个人计算机上都能找到的并口就是这样的非通用的I/O端口。

并口简介

并口的最小配置由3个8位端口组成。第一个端口是一个双向的数据寄存器，它直接连接到物理连接器的2~9号引脚上。第二个端口是一个只读的状态寄存器;当并口连接打印机时，该寄存器 报告 打印机状态，如是否是线、缺纸、正忙等等。第三个端口是一个只用于输出的控制寄存器，它的作用之一是控制是否启用中断。

如下所示：并口的引脚

示例驱动程序

while(count--) {

outb(*(ptr++), port);

wmb();

}

使用I/O内存

除了x86上普遍使的I/O端口之外，和设备通信的另一种主要机制是通过使用映射到内存的寄存器或设备内存，这两种都称为I/O内存，因为寄存器和内存的差别对软件是透明的。

I/O内存仅仅是类似RAM的一个区域，在那里处理器可以通过总线访问设备。这种内存有很多用途，比如存放视频数据或以太网数据包，也可以用来实现类似I/O端口的设备寄存器(也就是说，对它们的读写也存在边际效应)。

根据计算机平台和所使用总线的不同，i/o内存可能是，也可能不是通过页表访问的。如果访问是经由页表进行的，内核必须首先安排物理地址使其对设备驱动程序可见(这通常意味着在进行任何I/O之前必须先调用ioremap)。如果访问无需页表，那么I/O内存区域就非常类似于I/O端口，可以使用适当形式的函数读取它们。

不管访问I/O内存是否需要调用ioremap，都不鼓励直接使用指向I/O内存的指针。相反使用包装函数访问I/O内存，这一方面在所有平台上都是安全的，另一方面，在可以直接对指针指向的内存区域执行操作的时候，这些函数是经过优化的。并且直接使用指针会影响程序的可移植性。

I/O内存分配和映射

在使用之前，必须首先分配I/O区域。分配内存区域的接口如下(在<linux/ioport.h>中定义)：

struct resource *request_mem_region(unsigned long start, unsigned long len, char *name);

该函数从start开始分配len字节长的内存区域。如果成功返回非NULL，否则返回NULL值。所有的I/O内存分配情况可从/proc/iomem得到。

不再使用已分配的内存区域时，使用如下接口释放：

void release_mem_region(unsigned long start, unsigned long len);

下面函数用来检查给定的I/O内存区域是否可用的老函数：

int check_mem_region(unsigned long start, unsigned long len);//这个函数和check_region一样不安全，应避免使用

分配内存之后我们还必须确保该I/O内存对内存而言是可访问的。获取I/O内存并不意味着可引用对应的指针;在许多系统上，I/O内存根本不能通过这种方式直接访问。因此，我们必须由ioremap函数建立映射，ioremap专用于为I/O内存区域分配虚拟地址。

我们根据以下定义来调用ioremap函数：

#include <asm/io.h>

void *ioremap(unsigned long phys_addr, unsigned long size);

void *ioremap_nocache(unsigned long phys_addr, unsigned long size);在大多数计算机平台上，该函数和ioremap相同：当所有I/O内存已属于非缓存地址时，就没有必要实现ioremap的独立的，非缓冲版本。

void iounmap(void *addr);

记住，由ioremap返回的地址不应该直接引用，而应该使用内核提供的accessor函数。

访问I/O内存

在某些平台上我们可以将ioremap的返回值直接当作指针使用。但是，这种使用不具有可移植性，访问I/O内存的正确方法是通过一组专用于些目的的函数(在<asm/io.h>中定义)。

从I/O内存中读取，可使用以下函数之一：

unsigned int ioread8(void *addr);

unsigned int ioread16(void *addr);

unsigned int ioread32(void *addr);

其中，addr是从ioremap获得的地址(可能包含一个整数偏移量);返回值是从给定I/O内存读取到的值。

写入I/O内存的函数如下：

void iowrite8(u8 value, void *addr);

void iowrite16(u16 value, void *addr);

void iowrite32(u32 value, void *addr);

如果必须在给定的I/O内存地址处读/写一系列值，则可使用上述函数的重复版本：

void ioread8_rep(void *addr, void *buf, unsigned long count);

void ioread16_rep(void *addr, void *buf, unsigned long count);

void ioread32_rep(void *addr, void *buf, unsigned long count);

void iowrite8_rep(void *addr, const void *buf, unsigned long count);

void iowrite16_rep(void *addr, const void *buf, unsigned long count);

void iowrite32_rep(void *addr, const void *buf, unsigned long count);

上述函数从给定的buf向给定的addr读取或写入count个值。count以被写入数据的大小为单位。

上面函数均在给定的addr处执行所有的I/O操作，如果我们要在一块I/O内存上执行操作，则可以使用下面的函数：

void memset_io(void *addr, u8 value, unsigned int count);

void memcpy_fromio(void *dest, void *source, unsigned int count);

void memcpy_toio(void *dest, void *source, unsigned int count);

上述函数和C函数库的对应函数功能一致。

像I/O内存一样使用I/O端口

某些硬件具有一种有趣的特性：某些版本使用I/O端口，而其他版本则使用I/O内存。导出给处理器的寄存器在两种情况下都是一样的，但访问方法却不同。为了让处理这类硬件的驱动程序更加易于编写，也为了最小化I/O端口和I/O内存访问这间的表面区别，2.6内核引入了ioport_map函数：

void *ioport_map(unsigned long port, unsigned int count);

该函数重新映射count个I/O端口，使其看起来像I/O内存。此后，驱动程序可在该函数返回的地址上使用ioread8及其相关函数，这样就不必理会I/O端口和I/O内存之间的区别了。

当不需要这种映射时使用下面函数一撤消：

void ioport_unmap(void *addr);

这些函数使得I/O端口看起来像内存。但需要注意的是，在重新映射之前，我们必须通过request_region来分配这些I/O端口。

为I/O内存重用short

前面介绍的short示例模块访问的是I/O端口，它也可以访问I/O内存。为此必须在加载时通知它使用I/O内存，另外还要修改base地址以使其指向I/O区域。

下例是在MIPS开发板上点亮调试用的LED：

mips.root# ./short_load use_mem=1 base = 0xb7ffffc0

mips.root# echo -n 7 > /dev/short0

下面代码是short写入内存区域时使用的循环：

while(count--) {

iowrite8(*ptr++, address);

wmb();

}

1MB地址空间之下的ISA内存

最广为人知的I/O内存区之一就是个人计算机上的ISA内存段。它的内存范围在64KB(0xA0000)到1MB(0x100000)之间，因此它正好出现在常规系统RAM的中间。这种地址看上去有点奇怪，因为这个设计决策是20世纪80年代早期作出的，在当时看来没有人会用到640KB以上的内存。

❷ 如何学习Linux设备驱动

通常，内核的升级对从事linux应用程序开发的人员来说影响较小，因为系统调用基本保持兼容，影响比较大的是驱动开发人员。每次内核的更新都可能导致许多内核函数原型上的变化，其中既有内核本身提供的函数，也有硬件平台代码提供的函数，后者变化的更加频繁。这一点从许多经典书籍就可验证，当你按照手里的经典著作，如：Alessandro的《linux设备驱动程序》，编写驱动时，发现并不能够成功的在你的linux平台上编译通过、或不能正常执行，原因就在于你用的内核和书里的不一致。
本文从两个方面去解释这个问题，一方面是如何写好linux设备驱动，另一方面是如何应对不断升级的内核。
如何写好Linux设备驱动
Linux设备驱动是linux内核的一部分，是用来屏蔽硬件细节，为上层提供标准接口的一种技术手段。为了能够编写出质量比较高的驱动程序，要求工程师必须具备以下几个方面的知识：
● 熟悉处理器的性能
如：处理器的体系结构、汇编语言、工作模式、异常处理等。对于初学者来说，在还不熟悉驱动编写方法的情况下，可以先不把重心放在这一项上，因为可能因为它的枯燥、抽象而影响到你对设备驱动的兴趣。随着你不断地熟悉驱动的编写，你会很自然的意识到此项的重要性。
● 掌握驱动目标的硬件工作原理及通讯协议
如：串口控制器、显卡控制器、硬件编解码、存储卡控制器、I2C通讯、SPI通讯、USB通讯、SDIO通讯、I2S通讯、PCI通讯等。编写设备驱动的前提就是需要了解设备的操作方法，所以这些内容的重要程度不言而喻。但不是说要把所有设备的操作方法都熟悉了以后才可以写驱动，你只需要了解你要驱动的硬件就可以了。
● 掌握硬件的控制方法
如：中断、轮询、DMA 等，通常一个硬件控制器会有多种控制方法，你需要根据系统性能的需要合理的选择操作方法。初学阶段以实现功能为目的，掌握的顺序应该是，轮询->中断->DMA。随着学习的深入，需要综合考虑系统的性能需求，采取合适的方法。
● 良好的GNU C语言编程基础
如：C语言的指针、结构体、内存操作、链表、队列、栈、C和汇编混合编程等。这些编程语法是编写设备驱动的基础，无论对于初学者还是有经验者都非常重要。
● 良好的linux操作系统概念
如：多进程、多线程、进程调度、进程抢占、进程上下文、虚拟内存、原子操作、阻塞、睡眠、同步等概念及它们之间的关系。这些概念及方法在设备驱动里的使用是linux设备驱动区别单片机编程的最大特点，只有理解了它们才会编写出高质量的驱动。
● 掌握linux内核中设备驱动的编写接口
如：字符设备的cdev、块设备的gendisk、网络设备的net_device，以及基于这些基本接口的framebuffer设备的fb_info、mtd设备的mtd_info、tty设备的tty_driver、usb设备的usb_driver、mmc设备的mmc_host等。
Linux内核为设备驱动编写者提供了标准的接口，驱动编写者无需精通内核的各个部分，只需要明确内核提供给我们的接口，并实现此接口就可以了。内核提供的接口采用的是面向对象的思路，即把目标设备抽象成一个对象，通常利用一个结构体来描述这个对象。驱动工程师的任务就是实现这个对象。这个结构体中会包含设备的属性（用变量表示）和操作方法（用函数指针表示）。如：字符设备的cdev
struct cdev {
struct kobject kobj;
struct mole *owner;
const struct file_operations *ops; // 操作方法结合，其它项都是属性
struct list_head list;
dev_t dev;
unsigned int count;
};
开始阶段可以以模仿为主，即套用一些固定的模板、参考例程。
如何应对不断升级的内核
内核升级对驱动的影响主要体现在，（1）驱动接口定义的变化；（2）内核的一些功能函数的名称、参数、头文件、宏定义的变化；（3）平台代码关于硬件操作方面封装的一些函数的变化；（4）设备模型的影响。
● 驱动接口定义的变化
如：2.4内核中字符设备驱动的注册接口是：
int register_chrdev(unsigned int major, const char * name, struct file_operations *fops)
而2.6内核中已经不建议使用这种方法了，改为：
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
这种接口定义及注册方法带来的变化，发生的并不频繁。解决方案是：参考内核中的代码。这种接口定义及注册方法在内核中非常容易找到，如：字符设备驱动的注册方法及接口定义可以参照内核driver/char/目录下的很多实例。
● 内核的一些功能函数的名称、参数、头文件、宏定义的变化
如：中断注册函数的格式及参数在2.4内核、2.6内核低版本和高版本之间都存在差别，在2.6.8中，中断注册函数的定义为：
int request_irq(unsigned int irq, irqreturn_t (*handler)(int, void *, struct pt_regs *),unsigned long irq_flags, const char * devname, void *dev_id)
irq_flags的取值主要为下面的某一种或组合： SA_INTERRUPT、SA_SAMPLE_RANDOM、SA_SHIRQ
在2.6.26中，中断注册函数的定义为：
int request_irq(unsigned int irq, irq_handler_t handler,unsigned long irqflags, const char *devname, void *dev_id)
typedef irqreturn_t (*irq_handler_t)(int, void *); irq_flags的取值主要为下面的某一种或组合：（功能和2.6.8的对应）IRQF_DISABLED、IRQF_SAMPLE_RANDOM、IRQF_SHARED
当出现这些问题时，编译过程中，编译器会给我们比较明确的错误提示，根据这些提示你可以判断出是否是缺少头文件问题、是否是函数参数定义有误等。解决问题的最好办法还是到你的目标内核中找信息。此时找问题的方法可以借助于搜索，如：你可以在新的内核中搜索request_irq，看新内核中的驱动是如何使用它的，这种方法非常有效。
● 平台代码关于硬件操作方面封装的一些函数的变化
内核中，硬件平台相关的代码在内核更新过程中变化比较频繁，和我们的设备驱动也是息息相关，所以在针对一个新内核编写设备驱动前，一定要熟悉你的平台代码的结构。有时平台虽然提供了内核要求的接口函数，但使用起来功能却并不完善。下面还是先举个例子说明平台代码更新对设备驱动的影响。
如：在linux-2.6.8内核中，调用set_irq_type(IRQ_EINT0,IRQT_FALLING);去设置S3C2410的IRQ_EINT0的中断触发信号类型，你会发现不会有什么效果。跟踪代码发现内核的set_irq_type函数需要平台提供一个针对硬件平台的实现函数
static struct irqchip s3c_irqext_chip = {
.mask = s3c_irqext_mask,
.unmask = s3c_irqext_unmask,
.ack = s3c_irqext_ack,
.type = s3c_irqext_type
};
s3c_irqext_type就是linux内核需要的实现函数，而s3c_irqext_type在2.6.8中的实现为： static int s3c_irqext_type(unsigned int irq, unsigned int type)
{
irqdbf("s3c_irqext_type: called for irq %d, type %d\n", irq, type);
return 0;
}
原来并没有实现。而在较高版本的内核，如2.6.26内核中，这个函数是实现了的。所以你一定要小心。当平台函数不好用时，一定要查查原因，或者直接操作硬件寄存器来达到目的。
● 2.6内核设备模型对驱动的影响
在2.6内核中写设备驱动和在2.4内核中有着很大的不同，主要就是在设备驱动中融入了比设备驱动本身结构还复杂、还难以理解的设备模型。初学驱动时你可以不理会设备模型，但你会发现内核里的驱动代码基本上都是融入了设备模型的了。所以很多时候你不得不面对现实，还是要弄懂它，并且它也的注册方法也会随着内核的升级而发生变化。解决此类问题的最好方法还是参考目标内核驱动代码。

❸ linux设备驱动好学么需要什么基础

你好，首先我要说明我是ARM嵌入式开发工程师，偏驱动向
驱动难，没有3年以上的工作经验 都没专什么料子的
要写驱动属
你要很熟悉linux C 而且注重字符串和指针处理
然后你就学数字电路 要多懂
其次要学会看datasheet
这些学得差不多了就进入了内核，为什么要知道内核（只需要知道内核的工作原理机制还有版本变动），因为内核跟驱动是不分家的，你写了驱动就知道
然后就是进入主菜，写驱动，看书时必须的，我看驱动的书不下10本，而且尽量消化，随后你就尝试写某些驱动，只要你会一个类型的就会这一类型的驱动，同类驱动是万变不离其宗 不要想着全部驱动都学会，要学精！像NV realtek这些厉害的工程师 一辈子就写两个驱动（当然，所有驱动中为网卡驱动和显卡驱动最难最容易出错！同时也是最厉害的人去写的）
驱动！路漫漫其修远兮！

❹ linux驱动程序结构框架及工作原理分别是什么

一、Linux device driver 的概念x0dx0ax0dx0a系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能:x0dx0ax0dx0a1、对设备初始化和释放；x0dx0ax0dx0a2、把数据从内核传送到硬件和从硬件读取数据；x0dx0ax0dx0a3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据；x0dx0ax0dx0a4、检测和处理设备出现的错误。x0dx0ax0dx0a在Linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。x0dx0ax0dx0a已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。x0dx0ax0dx0a最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。x0dx0ax0dx0a二、实例剖析x0dx0ax0dx0a我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。x0dx0ax0dx0a由于用户进程是通过设备文件同硬件打交道，对设备文件的操作方式不外乎就是一些系统调用，如 open，read，write，close?， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：x0dx0ax0dx0aSTruct file_operatiONs {x0dx0ax0dx0aint (*seek) (struct inode * ，struct file *， off_t ，int);x0dx0ax0dx0aint (*read) (struct inode * ，struct file *， char ，int);x0dx0ax0dx0aint (*write) (struct inode * ，struct file *， off_t ，int);x0dx0ax0dx0aint (*readdir) (struct inode * ，struct file *， struct dirent * ，int);x0dx0ax0dx0aint (*select) (struct inode * ，struct file *， int ，select_table *);x0dx0ax0dx0aint (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);x0dx0ax0dx0aint (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);x0dx0ax0dx0aint (*open) (struct inode * ，struct file *);x0dx0ax0dx0aint (*release) (struct inode * ，struct file *);x0dx0ax0dx0aint (*fsync) (struct inode * ，struct file *);x0dx0ax0dx0aint (*fasync) (struct inode * ，struct file *，int);x0dx0ax0dx0aint (*check_media_change) (struct inode * ，struct file *);x0dx0ax0dx0aint (*revalidate) (dev_t dev);x0dx0ax0dx0a}x0dx0ax0dx0a这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。x0dx0ax0dx0a下面就开始写子程序。x0dx0ax0dx0a#include 基本的类型定义x0dx0ax0dx0a#include 文件系统使用相关的头文件x0dx0ax0dx0a#include x0dx0ax0dx0a#include x0dx0ax0dx0a#include x0dx0ax0dx0aunsigned int test_major = 0;x0dx0ax0dx0astatic int read_test(struct inode *inode，struct file *file，char *buf，int count)x0dx0ax0dx0a{x0dx0ax0dx0aint left; 用户空间和内核空间x0dx0ax0dx0aif (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )x0dx0ax0dx0areturn -EFAULT;x0dx0ax0dx0afor(left = count ; left > 0 ; left--)x0dx0ax0dx0a{x0dx0ax0dx0a__put_user(1，buf，1);x0dx0ax0dx0abuf++;x0dx0ax0dx0a}x0dx0ax0dx0areturn count;x0dx0ax0dx0a}x0dx0ax0dx0a这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。x0dx0ax0dx0astatic int write_test(struct inode *inode，struct file *file，const char *buf，int count)x0dx0ax0dx0a{x0dx0ax0dx0areturn count;x0dx0ax0dx0a}x0dx0ax0dx0astatic int open_test(struct inode *inode，struct file *file )x0dx0ax0dx0a{x0dx0ax0dx0aMOD_INC_USE_COUNT; 模块计数加以，表示当前内核有个设备加载内核当中去x0dx0ax0dx0areturn 0;x0dx0ax0dx0a}x0dx0ax0dx0astatic void release_test(struct inode *inode，struct file *file )x0dx0ax0dx0a{x0dx0ax0dx0aMOD_DEC_USE_COUNT;x0dx0ax0dx0a}x0dx0ax0dx0a这几个函数都是空操作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。x0dx0ax0dx0astruct file_operations test_fops = {?x0dx0ax0dx0aread_test，x0dx0ax0dx0awrite_test，x0dx0ax0dx0aopen_test，x0dx0ax0dx0arelease_test，x0dx0ax0dx0a};x0dx0ax0dx0a设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(moles)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。x0dx0ax0dx0aint init_mole(void)x0dx0ax0dx0a{x0dx0ax0dx0aint result;x0dx0ax0dx0aresult = register_chrdev(0， "test"， &test_fops); 对设备操作的整个接口x0dx0ax0dx0aif (result < 0) {x0dx0ax0dx0aprintk(KERN_INFO "test: can't get major number\n");x0dx0ax0dx0areturn result;x0dx0ax0dx0a}x0dx0ax0dx0aif (test_major == 0) test_major = result; /* dynamic */x0dx0ax0dx0areturn 0;x0dx0ax0dx0a}x0dx0ax0dx0a在用insmod命令将编译好的模块调入内存时，init_mole 函数被调用。在这里，init_mole只做了一件事，就是向系统的字符设备表登记了一个字符设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，参数三用来登记驱动程序实际执行操作的函数的指针。x0dx0ax0dx0a如果登记成功，返回设备的主设备号，不成功，返回一个负值。x0dx0ax0dx0avoid cleanup_mole(void)x0dx0ax0dx0a{x0dx0ax0dx0aunregister_chrdev(test_major，"test");x0dx0ax0dx0a}x0dx0ax0dx0a在用rmmod卸载模块时，cleanup_mole函数被调用，它释放字符设备test在系统字符设备表中占有的表项。x0dx0ax0dx0a一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。x0dx0ax0dx0a下面编译 :x0dx0ax0dx0a$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c _c表示输出制定名，自动生成.o文件x0dx0ax0dx0a得到文件test.o就是一个设备驱动程序。x0dx0ax0dx0a如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后x0dx0ax0dx0ald ?-r ?file1.o ?file2.o ?-o ?molename。x0dx0ax0dx0a驱动程序已经编译好了，现在把它安装到系统中去。x0dx0ax0dx0a$ insmod ?_f ?test.ox0dx0ax0dx0a如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :x0dx0ax0dx0a$ rmmod testx0dx0ax0dx0a下一步要创建设备文件。x0dx0ax0dx0amknod /dev/test c major minorx0dx0ax0dx0ac 是指字符设备，major是主设备号，就是在/proc/devices里看到的。x0dx0ax0dx0a用shell命令x0dx0ax0dx0a$ cat /proc/devicesx0dx0ax0dx0a就可以获得主设备号，可以把上面的命令行加入你的shell script中去。x0dx0ax0dx0aminor是从设备号，设置成0就可以了。x0dx0ax0dx0a我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。x0dx0ax0dx0a#include x0dx0ax0dx0a#include x0dx0ax0dx0a#include x0dx0ax0dx0a#include x0dx0ax0dx0amain()x0dx0ax0dx0a{x0dx0ax0dx0aint testdev;x0dx0ax0dx0aint i;x0dx0ax0dx0achar buf[10];x0dx0ax0dx0atestdev = open("/dev/test"，O_RDWR);x0dx0ax0dx0aif ( testdev == -1 )x0dx0ax0dx0a{x0dx0ax0dx0aprintf("Cann't open file \n");x0dx0ax0dx0aexit(0);x0dx0ax0dx0a}x0dx0ax0dx0aread(testdev，buf，10);x0dx0ax0dx0afor (i = 0; i < 10;i++)x0dx0ax0dx0aprintf("%d\n"，buf[i]);x0dx0ax0dx0aclose(testdev);x0dx0ax0dx0a}x0dx0ax0dx0a编译运行，看看是不是打印出全1 x0dx0ax0dx0a以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。上述给出了一个简单的字符设备驱动编写的框架和原理，更为复杂的编写需要去认真研究LINUX内核的运行机制和具体的设备运行的机制等等。希望大家好好掌握LINUX设备驱动程序编写的方法。

❺ Linux驱动与设备节点简介 & Android内核与Linux内核的区别

驱动是内核的一部分，作为直接访问物理硬件的一个软件层，用于应用程序与物理硬件设备通信。内核包含多种驱动，如WIFI、USB、Audio、蓝牙、相机、显示驱动。

（1）设备驱动程序三类：字符设备驱动程序、块设备驱动程序、网络设备驱动程序；

（2）对应Linux三类设备：字符设备、块设备、网络设备；

（3）常见字符设备：鼠标、键盘、串口、控制台等；

（4）常见块设备：各种硬盘、flash磁盘、RAM磁盘等；

（5）网络设备(网络接口)：eth0、eth1，注：网络设备没有设备节点，应用程序通过Socket访问网络设备。由于网络设备面向报文，较难实现相关read、write等文件读写函数，所以驱动的实现也与字符设备和块设备不同。

Linux使用对文件一样的管理方式来管理设备，所有设备都以文件的形式存放在/dev目录下，系统中的每个字符设备或者块设备都必须为其创建一个设备文件，它包含了该设备的设备类型（块设备或字符设滚桥备）、设备号（主设备号和次设备号）以及设备访问控制属性等。设备节点通过 mknod 命令创建，也可以由Udev用户工具软件在系统启动后根据/sys目录下每个设备的实际信息创建，使用后一种方式可以为每个设备动态分配设备号。

Linux中设备节点通过“mknod”命令创建，创建时需要指定主设备号和次设备号，即指定对应的驱动程序和对应的物理设备（访问设备节点时就相当于通过其设备号访问驱动程序进而间接访问到物理设备）。主设备号用来区分不同种类的设备，而次设备号用来区分同一类大举猛型的多个设备。对于常用设备，Linux有约定俗成的编号，如硬盘的主设备号是3

理解：应用程序通过访问设备节点读取主设备号和次设备号，通过主设答枯备号找对应的驱动，通过次设备号对应到具体物理设备。注：1个驱动对应一类设备，并用唯一主设备号标识。

Linux支持的各种设备的主设备号定义在include/linux/major.h文件中，已经在官方注册的主设备号和次设备号在Documentation/devices.txt文件中。

Android系统最底层是Linux，并且在中间加上了一个Dalvik / ART的Java虚拟机，从表面层看是Android运行库。每个Android应用都运行在自己的进程上，享有Dalvik / ART虚拟机为它分配的专有实例，并支持多个虚拟机在同一设备上高效运行，虚拟机执行的是专有格式的可执行文件(.dex) - 该格式经过优化，以将内存好用降到最低。

Android内核和Linux内核的差别主要体现在如下11个方面：

❻ Linux网络设备驱动的结构

Linux网络设备驱动程序的体系结构从上到下可以划分为4层，依次为网络协议接口层、网络设备接口层、提供实际功能的设备驱动功能层以及网络设备与媒介层，这4层的作用如下所示。
1）网络协议接口层向网络层协议提供统一的数据包收发接口，不论上层协议是ARP，还是IP，都通过dev_queue_xmit() 函数发送数据，并通过netif rx ()函数接收数据。这一层的存在使得上层协议独立于具体的设备。
2）网络设备接口层向协议接口层提供统一的用于描述具体网络设备属性和操作的结构体net device,该结构体是设备驱动功能层中各函数的容器。实际上，网络设备接口层从宏观上规划了具体操作硬件的设备驱动功能层的结构。
3）设备驱动功能层的各函数是网络设备接口层net_device数据结构的具体成员，是驱使网络设备硬件完成相应动作的程序，它通过hard_start_ xmit ()函数启动发送操作，并通过网络设备上的中断触发接收操作。
4）网络设备与媒介层是完成数据包发送和接收的物理实体，包括网络适配器和具体的传输媒介，网络适配器被设备驱动功能层中的函数在物理上驱动。对于Linux系统而言，网络设备和媒介都可以是虚拟的。

❼ 《Linux设备驱动程序》（十六）-中断处理

设备与处理器之间的工作通常来说是异步，设备数据要传递给处理器通常来说有以下几种方法：轮询、等待和中断。

让CPU进行轮询等待总是不能让人满意，所以通常都采用中断的形式，让设备来通知CPU读取数据。

2.6内核的函数参数与现在的参数有所区别，这里都主要介绍概念，具体实现方法需要结合具体的内核版本。

request_irq函数申请中断，返回0表示申请成功，其他返回值表示申请失败，其具体参数解释如下：

flags 掩码可以使用以下几个：

快速和慢速处理例程 ：现代内核中基本没有这两个概念了，使用SA_INTERRUPT位后，当中断被执行时，当前处理器的其他中断都将被禁止。通常不要使用SA_INTERRUPT标志位，除非自己明确知道会发生什么。

共享中断 ：使用共享中断时，一方面要使用SA_SHIRQ位，另一个是request_irq中的dev_id必须是唯一的，不能为NULL。这个限制的原因是：内核为每个中断维护了一个共享处理例程的列表，例程中的dev_id各不相同，就像设备签名。如果dev_id相同，在卸载的时候引起混淆（卸载了另一个中断），当中断到达时会产生内核OOP消息。

共享中断需要满足以下一个条件才能申请成功：

当不需要使用该中断时，需要使用free_irq释放中断。

通常我们会在模块加载的时候申请安装中断处理例程，但书中建议：在设备第一次打开的时候安装，在设备最后一次关闭的时候卸载。

如果要查看中断触发的次数，可以查看 /proc/interrupts 和 /proc/stat。

书中讲述了如何自动检测中断号，在嵌入式开发中通常都是查看原理图和datasheet来直接确定。

自动检测的原理如下：驱动程序通知设备产生中断，然后查看哪些中断信号线被触发了。Linux提供了以下方法来进行探测：

探测工作耗时较长，建议在模块加载的时候做。

中断处理函数和普通函数其实差不多，唯一的区别是其运行的中断上下文中，在这个上下文中有以下注意事项：

中断处理函数典型用法如下：

中断处理函数的参数和返回值含义如下：

返回值主要有两个：IRQ_NONE和IRQ_HANDLED。

对于中断我们是可以进行开启和关闭的，Linux中提供了以下函数操作单个中断的开关：

该方法可以在所有处理器上禁止或启用中断。

需要注意的是：

如果要关闭当前处理器上所有的中断，则可以调用以下方法：

local_irq_save 会将中断状态保持到flags中，然后禁用处理器上的中断；如果明确知道中断没有在其他地方被禁用，则可以使用local_irq_disable，否则请使用local_irq_save。

locat_irq_restore 会根据上面获取到flags来恢复中断；local_irq_enable 会无条件打开所有中断。

在中断中需要做一些工作，如果工作内容太多，必然导致中断处理所需的时间过长；而中断处理又要求能够尽快完成，这样才不会影响正常的系统调度，这两个之间就产生了矛盾。

现在很多操作系统将中断分为两个部分来处理上面的矛盾：顶半部和底半部。

顶半部就是我们用request_irq来注册的中断处理函数，这个函数要求能够尽快结束，同时在其中调度底半部，让底半部在之后来进行后续的耗时工作。

顶半部就不再说明了，就是上面的中断处理函数，只是要求能够尽快处理完成并返回，不要处理耗时工作。

底半部通常使用tasklet或者工作队列来实现。

tasklet的特点和注意事项：

工作队列的特点和注意事项：

❽ linux主机侧与设备侧USB驱动

USB采用树形拓扑结构，主机侧和设备侧的USB控制器分别称为主机控制器（(Host Controller）和USB设备控制器(UDC)，每条总线上只有一个主机控制器，负责协调主机和设备间的通信，而设备不能主动向主机发送任何消息。

在Linux系统中，USB驱动可以从两个角度去观察，一个角度是主机侧，一个角度是设备侧。从上图主机侧去看，在Linux驱动中，处于USB驱动最底层的是USB主机控制器硬件，在其上运行的是USB主机控制器驱动，在主机控制器上的为USB核心层，再上层为USB设备驱动层(插入主机上的U盘、鼠标、USB转串口等设备驱动）。因此，在主机侧的层次结构中，要实现的USB驱动包括两类:USB主机控制器驱动和USB设备驱动，前者控制插入其中的USB设备，后者控制USB设备如何与主机通信。Linux内核中的USB核心负责USB驱动管理和协议处理的主要工作。主机控制器驱动和设备驱动之间的USB核心非常重要，其功能包括:通过定义一些数据结构、宏和功能函数，向上为设备驱动提供编程接口，向下为USB主机控制器驱动提供编程接口;维护整个系统的USB设备信息;完成设备热插拔控制、总线数据传输控制等。