LDD3源码分析之与硬件通信&中断处理
LDD3源码分析之与硬件通信&中断处理
分类： LDD3源码分析
2012-04-11 08:45
293人阅读
评论(0)
收藏
举报
作者：刘昊昱
博客：http://blog.csdn.net/liuhaoyutz
编译环境：Ubuntu 10.10
内核版本：2.6.32-38-generic-pae
LDD3源码路径：examples/short/
本分析LDD3第9和第10章的示例代码short。short涉及的主要知识点有通过I/O端口或I/O内存操作设备寄存器及设备内存，注册中断处理函数处理中断。本来第9和第10章的代码应该分别进行讨论，但是因为short的代码相互关联比较紧密，所以这里放在同一篇文章中分析。
一、short模块编译
在新的内核下，编译short模块时，会遇到一些问题，这里列出遇到的问题及解决方法。
第一次make时，出现如下错误：
修改Makefile的第12，13，35行，将CFLAGS改为EXTRA_CFLAGS，即可解决这个问题。再次make,会出现如下错误：
修改short.c，把第24行#include <linux/config.h>屏蔽掉。再次编译出现如下问题：
这是因为SA_INTERRUPT和SA_SHIRQ标志在新内核中发生了变化，SA_INTERRUPT标志已经不存在了，SA_SHIRQ标志位变为IRQF_SHARED。所以做以下修改：
514，638，658行把flag标志设置为0，624行把flag设置为IRQF_SHARED，修改完成后，再次编译，出现如下错误：
修改597行为INIT_WORK(&short_wq, (void (*)(struct work_struct *)) short_do_tasklet);
再次make，编译通过，但还有一些警告信息如下：
这是因为在新的内核版本中中断处理函数的原型只有两个参数，而在2.6.10中有三个参数，这里只要把相应中断处理函数的第三个参数去掉即可，修改后的函数原型如下：
494irqreturn_t short_probing(int irq, void *dev_id)
443irqreturn_t short_sh_interrupt(int irq, void *dev_id)
431irqreturn_t short_tl_interrupt(int irq, void *dev_id)
413irqreturn_t short_wq_interrupt(int irq, void *dev_id)
336irqreturn_t short_interrupt(int irq, void *dev_id)
再次编译，通过。
二、short模块初始化
先来看short模块初始化函数：
561 - 567行，如果指定使用I/O端口，则调用request_region函数分配I/O端口，这里代码指定要分配从short_base开始的SHORT_NR_PORTS个即8个端口。
568 - 578行，如果指定使用I/O内存，则调用request_mem_region函数分配从short_base开始的SHORT_NR_PORTS个即8个字节的I/O内存。分配I/O内存并不是在使用这些内存之前需要完成的唯一步骤，我们必须首先通过ioremap函数建立映射。ioremap返回用来访问指定物理内存的虚拟地址。
580 - 586行，注册字符设备short", 其文件操作函数集是short_fops。
588行，调用__get_free_pages(GFP_KERNEL,0)分配一个页面保存在 short_buffer中。
597行，调用INIT_WORK初始化一个工作，将来用作中断处理函数的下半部。
604 - 605行，如果short_irq<0并且probe等于1，则调用short_kernelprobe函数由内核探测中断号。该函数的实现我们后面分析。
607 - 608行，如果short_irq<0并且probe等于2，则调用short_selfprobe函数自己手动探测中断号，该函数的实现我们后面分析。
610 - 615行，如果探测没有成功，根据端口地址，强制指定中断号。
622 - 634行，以共享中断的方式注册中断处理函数。需要注意的是631行调用outb(0x10, short_base+2),将并口2号寄存器的第4位置为1，表示启动并口中断报告。
636 - 647行，以非共享中断的方式注册中断处理函数。
653 - 664行，以上半部/下半部的方式注册中断处理函数。
下面我们来看short_kernelprobe函数如何实现由内核自动探测中断号的：
Linux内核提供了探测可用中断号的接口，但这种接口只能在非共享中断模式下使用。内核提供的接口由两个函数组成：
unsigned long probe_irq_on(void);
这个函数返回一个未分配中断的位掩码，驱动程序必须保存返回的位掩码，并将它传递给probe_irq_off函数。调用probe_irq_on函数之后，驱动程序要安排设备产生至少一次中断。
int probe_irq_off(unsigned long);
在请求设备产生中断之后，驱动程序要调用这个函数，并将前面probe_irq_on返回的位掩码作为参数传递给它。probe_irq_off返回probe_irq_on之后发生的中断编号。如果没有中断发生，就返回0。如果产生了多次中断，出现了二义性，就返回负数。
使用内核提供的接口探测中断号时，需要注意在调用probe_irq_on之后启用设备中断，在调用probe_irq_off之前禁用中断。另外，在probe_irq_off之后，需要处理设备上待处理的中断。
472行，调用probe_irq_on函数。
473行，将2号端口的第4位(0x10)设置为1，启用中断。
474行，将0号端口清0。
475行，将0号端口置1，触发中断。
476行，将2号端口的第4位(0x10)设置为0，禁用中断。
477行，延时一会，以保证中断的传递时间。
478行，调用probe_irq_off函数,并把472行probe_irq_on函数返回的位掩码传递给它。
480行，probe_irq_off函数返回0，说明没有中断发生。
489行，probe_irq_off函数返回负值，说明发生了不止一个中断，需要重新探测，这里限定最多探测5次。
下面我们看short_selfprobe函数如何实现DIY探测中断号：
DIY探测与内核自动探测的原理是一样的:先启动所有未被占用的中断,然后观察会发生什么。但是，我们要充分发挥对具体设备的了解。通常，设备能使用3或4个IRQ号中的一个来进行配置，探测这些IRQ号，使我们能不必测试所有可能的IRQ就能检测到正确的IRQ号。
并口允许用户选择的IRQ号有3，5，7，9，所以在short中，我们探测这几个中断号。
503行，trials数组列出了以0作为结束标志的需要测试的IRQ。
504行，tried数组用来记录哪个中断号被short驱动程序注册了。
512 - 514行，循环trials数组，为每个要探测的中断号注册中断处理函数short_probing。注意， request_irq函数如果注册成功，返回0保存在tried[i]中。
517 - 522行，触发中断，引起short_probing函数的执行。在short_probing函数中，将发生中断的中断号保存在short_irq中，如果发生多次中断，将设置short_irq值为负数。
525 - 527行，如果short_irq的值为0，说明没有发生中断。
533行，如果short_irq的值小于或等于0，则重新探测，最多探测5次。
536 - 538行，释放IRQ。
完成自动探测或DIY探测后，我们回到short_init函数：
610 - 615行，short_irq小于0，说明没有探测到中断号，short根据端口地址，强制指定默认中断号。
622 - 634行，如果(short_irq >= 0 && share > 0)，则以共享中断方式注册中断处理函数short_sh_interrupt。其中，631行使用outb(0x10, short_base + 2)启动中断报告。
636 - 647行，如果没有指定共享中断，则以非共享中断方式注册中断处理函数short_interrupt。其中645行outb(0x10,short_base+2)启动中断报告。
653 - 663行，注册以顶半部/底半部的方式执行中断处理。如果使用tasklet，对应的中断处理函数是short_tl_interrupt，如果使用工作队列，对应的中断处理函数是short_wq_interrupt。
按照在short_init中出现的顺序，下面我们要看short_sh_interrupt函数了：
注册共享的中断处理程序时，request_irq函数的flag参数必须指定SA_SHIRQ标志，同时dev_id参数必须是唯一的，任何指向模块地址空间的指针都可以使用，但是dev_id不能设置为NULL。
注销共享中断处理程序同样使用free_irq，传递dev_id参数用来从该中断的共享处理程序列表中选择指定的处理程序。这也是dev_id必须唯一的原因。
内核为每个中断维护了一个共享处理程序列表，这些处理程序的dev_id各不相同，就像是设备的签名。
当请求一个共享中断时，如果满足下面条件之一，request_irq就能成功：
1.中断号空闲。
2.任何已经注册了该中断号的处理例程也标识了中断号是共享的。
当共享的中断发生时，内核会调用每一个已经注册的中断处理函数，因此，一个共享中断的中断处理函数必须能识别属于自己的中断，如果不是自己的设备被中断，应该迅速退出。
449 - 451行，读取端口short_base，如果ACK位为1，则报告的中断就是发送给short的。如果为0，则是发给其它中断处理函数的，此时short_sh_interrupt应该立即退出。
454行，清除ACK位。
458行，获取当前时间。
459 - 460行，将时间信息保存在short_head中，在模块初始化函数short_init中，有如下语句：
588 short_buffer = __get_free_pages(GFP_KERNEL,0); /* never fails */ /* FIXME */
589 short_head = short_tail = short_buffer;
所以short_head指向缓冲区short_buffer的空闲起始位置。
461行，调用short_incr_bp函数更新空闲缓冲区头指针short_head位置。
462行，唤醒等待队列short_queue上的进程。
如果不是使用共享中断方式，在short_init函数中注册的中断处理函数是short_interrupt，该函数内容如下：
short_interrupt函数的内容和共享中断处理函数short_sh_interrupt的后半部分完全一样，这里不多解释，请参考对short_sh_interrupt函数的分析。
如果指定以顶半部/底半部的方式执行中断处理，在short_init函数中重新注册了中断处理函数，如果采用tasklet，则顶半部是short_tl_interrupt，如果采用工作队列，则顶半部是short_wq_interrupt。这两个函数列出如下：
在顶半部中，取得当前时间后，调用short_incr_tv函数将时间保存在tv_data数组中，然后调度tasklet或工作稍后执行：
short_incr_tv函数用到的几个变量定义如下：
工作short_wq的初始化在short_init函数中：
tasklet short_tasklet定义在第91行，如下：
由此可见，工作队列和tasklet的处理函数都是short_do_tasklet，它就是所谓的底半部函数：
在底半部函数中，把时间信息从tv_data数组中取出来，写到short_buffer缓冲区中，然后唤醒等待队列short_queue上的进程。这些进程将从short_buffer中读取时间信息。
三、文件操作函数
分析完了模块初始化函数,我们可以看设备文件操作函数了，文件操作函数集是short_fops：
先看short_open函数：
118 - 119行，如果次设备号的第8位为1，重新设置文件操作函数集为short_i_fops。理解这样的设置可以看一下ldd3自带的short_load脚本，该脚本创建的设备节点/dev/shortint和/dev/shortprint的次设备号分别为128和129，如果对这两个节点进行操作，采用short_i_fops，即使用中断。对其它节点的操作，使用非中断操作。
下面看short_read的实现：
138行，确定要访问的端口。
139行，确定要访问的内存地址。
注意，对一个设备节点来说，要么是采用I/O端口，要么是采用I/O内存，不可能两个同时用，所以137和138行只有一个起作用，这里只是为减少程序代码而写在一起。理解这两句话，需要联系模块初始化函数short_init中的如下代码：
回到do_short_read函数：
140行，确定mode值，要理解这句，也要参考LDD3自带的short_load脚本对设备节点次设备号的设置。/dev/short0 - /dev/short7次设备号是0 - 7，对应的mode是0，/dev/short0p - /dev/short7p次设备号是16 - 23，对应的mode是1，/dev/short0s - /dev/short7s次设备号是32 - 39，对应的mode是2。
151 - 153行，使用insb(port, ptr, count)，从port端口一次读count位数据到ptr指向的内存中;
157 - 160行，使用inb(port)一次从port端口读一个位数据，循环count次。
164 - 167行，使用ioread8(address)，从I/O内存address处读一个字节，循环count次。
169 - 173行，使用暂停式I/O函数inb_p(port)，一次从port端口读一个位数据，重复count次。
180行，将读到的数据拷贝到用户空间。
short_write函数的实现与short_read函数类似，只是方向相反而已，这里不再详细分析了。
下面我们来看使用中断的读函数short_i_read：
284行，创建等待队列入口wait。
286行，如果short_head等于short_tail，说明short_buffer缓冲区中没有数据可读，需要休眠等待。前面在分析中断处理函数时，我们已经看到在short设备的中断处理函数中，会将数据写入short_buffer缓冲区并唤醒等待队列中的进程。
287 - 289，进入休眠。
290 - 293，被唤醒后执行清理工作。
300行，拷贝short_tail开始的count个数据到用户空间。
302行，更新short_tail位置。
下面我们来看使用中断的写函数short_i_write：
313 - 315，使用I/O内存，调用iowrite8写数据。
316 - 318，使用I/O端口，调用outb写数据。