学步园

一、中断下半部-工作队列

1、中断

               先看一下宋宝华先生的《linux设备驱动开发详解》里面对中断的描述吧。这本书个人感觉 写的比较好，从开始学驱动到现在，还能从中得到不少知识。

               设备的中断会打断内核中进程的正常调度和运行，系统对更高吞吐率的追求势必要求中断服务程序尽可能地短小精悍。但是，这个良好的愿望往往与现实并不吻合。在大多数真实的系统中，当中断到来时，要完成的工作往往并不会是短小的，它可能要进行较大量的耗时处理。如下图描述了Linux内核的中断处理机制。为了在中断执行时间尽可能短和中断处理需完成大量工作之间找到一个平衡点，Linux将中断处理程序分解为两个半部：顶半部（top 
half）和底半部（bottom half）。顶半部完成尽可能少的比较紧急的功能，它往往只是简单地读取寄存器中的中断状态并清除中断标志后就进行“登记中断”的工作。“登记中断”意味着将底半部处理程序挂到该设备的底半部执行队列中去。这样，顶半部执行的速度就会很快，可以服务更多的中断请求。现在，中断处理工作的重心就落在了底半部的头上，它来完成中断事件的绝大多数任务。底半部几乎做了中断处理程序所有的事情，而且可以被新的中断打断，这也是底半部和顶半部的最大不同，因为顶半部往往被设计成不可中断。底半部则相对来说并不是非常紧急的，而且相对比较耗时，不在硬件中断服务程序中执行。尽管顶半部、底半部的结合能够改善系统的响应能力，但是，僵化地认为Linux设备驱动中的中断处理一定要分两个半部则是不对的。如果中断要处理的工作本身很少，则完全可以直接在顶半部全部完成。

           其实上面这一段大致说明一个问题，那就是：中断要尽可能耗时比较短，尽快恢复系统正常调试，所以把中断触发、中断执行分开，也就是所说的“上半部分（中断触发）、底半部（中断执行）”，其实就是我们后面说的中断上下文。下半部分一般有tasklet、工作队列实现，触摸屏中中断实现以工作队列形式实现的，所以我们今天重点讲工作队列。

2、为什么还需要工作队列？

           工作队列（work queue）是另外一种将中断的部分工作推后的一种方式，它可以实现一些tasklet不能实现的工作，比如工作队列机制可以睡眠。这种差异的本质原因是，在工作队列机制中，将推后的工作交给一个称之为工作者线程（worker thread）的内核线程去完成（单核下一般会交给默认的线程events/0）。因此，在该机制中，当内核在执行中断的剩余工作时就处在进程上下文（process
context）中。也就是说由工作队列所执行的中断代码会表现出进程的一些特性，最典型的就是可以重新调度甚至睡眠。

             对于tasklet机制（中断处理程序也是如此），内核在执行时处于中断上下文（interrupt context）中。而中断上下文与进程毫无瓜葛，所以在中断上下文中就不能睡眠。因此，选择tasklet还是工作队列来完成下半部分应该不难选择。当推后的那部分中断程序需要睡眠时，工作队列毫无疑问是你的最佳选择；否则，还是用tasklet吧。

3、中断上下文

          有上面那个图可以看出上下两部分吧，就是上下文吧，这个比较好理解。

          看下别人比较专业的解释：

          在了解中断上下文时，先来回顾另一个熟悉概念：进程上下文（这个中文翻译真的不是很好理解，用“环境”比它好很多）。一般的进程运行在用户态，如果这个进程进行了系统调用，那么此时用户空间中的程序就进入了内核空间，并且称内核代表该进程运行于内核空间中。由于用户空间和内核空间具有不同的地址映射，并且用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行。这样就产生了进程上下文。

           所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈中的内容。当内核需要切换到另一个进程时（上下文切换），它需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态继续执行。上述所说的工作队列所要做的工作都交给工作者线程来处理，因此它可以表现出进程的一些特性，比如说可以睡眠等。              对于中断而言，是硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境，主要是被中断的进程的环境。因此处于中断上下文的tasklet不会有睡眠这样的特性。

4、工作队列的使用方法

内核中通过下述结构体来表示一个具体的工作：

           而这些工作（结构体）链接成的链表就是所谓的工作队列。工作者线程会在被唤醒时执行链表上的所有工作，当一个工作被执行完毕后，相应的work_struct结构体也会被删除。当这个工作链表上没有工作时，工作线程就会休眠。

（1）、通过如下宏可以创建一个要推后的完成的工作:

（2）、也可以通过下述宏动态创建一个工作:

与tasklet类似，每个工作都有具体的工作队列处理函数，原型如下:

将工作队列机制对应到具体的中断程序中，即那些被推后的工作将会在func所指向的那个工作队列处理函数中被执行。

（3）、实现了工作队列处理函数后，就需要schedule_work函数对这个工作进行调度，就像这样：

这样work会马上就被调度，一旦工作线程被唤醒，这个工作就会被执行（因为其所在工作队列会被执行）。

二、input子系统概述 可见文章基于 mini2440 电阻式触摸屏（三）：Linux输入子系统(InputSubsystem)：

            按键、鼠标、触摸屏、电池信息等，都是通过input子系统上报。

三、Linux与Android 多点触摸协议

            为了使用功能强大的多点触控设备，就需要一种方案去上报用户层所需的详细的手指触摸数据。这个文档所描述的多点触控协议可以让内核驱动程序向用户层上报任意多指的数据信息。

1、使用说明

            单点触摸信息是以ABS承载并按一定顺序发送，如BTN_TOUCH、ABS_X、ABS_Y、SYNC。而多点触摸信息则是以ABS_MT承载并按一定顺序发送，如ABS_MT_POSITION_X、ABS_MT_POSITION_Y，然后通过调用input_mt_sync（）产生一个 SYN_MT_REPORT event来标记一个点的结束，告诉接收方接收当前手指的信息并准备接收其它手指的触控信息。最后调用
input_sync（）函数上报触摸信息开始动作并告诉接收方开始接收下一系列多点触摸信息。

             协议定义了一系列ABS_MT事件，这些事件被分为几大类，充许只应用其中的一部份，多点触摸最小的事件集中应包括ABS_MT_TOUCH_MAJOR、ABS_MT_POSITION_X和 ABS_MT_POSITION_Y，以此来实现多点触摸。如果设备支持ABS_MT_WIDTH_MAJOR这个事件，那么此事件可以提供手指触摸接触面积大小。触摸方向等信息可以由ABS_MT_TOUCH_MINOR,
ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION提供。ABS_MT_TOOL_TYPE提供触摸设备的类别，如手或是笔或是其它。最后有些设备可能会支持ABS_MT_TRACKING_ID，用来支持硬件跟踪多点信息，即该点属于哪一条线等。

2、Event原语

                接触”一词用来描述一个物体直接碰到另一个物体的表面。

                ABS_MT_TOUCH_MAJOR描述了主接触面的长轴，它和X，Y同一个单位，如果一个面的分辨率为X*Y，则ABS_MT_TOUCH_MAJOR的最大值为sqrt（X^2+Y^2）

               以上四个参数可以用来生成额外的触摸信息，ABS_MT_TOUCH_MAJOR/ABS_MT_WIDTH_MAJOR的比率可以用来描述压力。

                ABS_MT_ORIENTATION

                ABS_MT_POSITION_X接触面的中心点X坐标

                ABS_MT_POSITION_Y接触面的中心点Y坐标

                ABS_MT_TOOL_TYPE描述接触工具类型，很多内核驱动无法区分此参数如手指及笔，如果是这样，该参数可以不用，协议目前支持MT_TOOL_FINGER和MT_TOOL_PEN两种类型。

                ABS_MT_BLOB_ID形状集ID，集合几个点以描述一个形状，很多驱动没有形状属性，此参数可以不用。ABS_MT_TRACKING_ID描述了从接触开始到释放的整个过程的集合，如果设备不支持，此参数可是不用。

3、触摸轨迹

            仅有少数设备可以明触的标识真实的 trackingID，多数情况下 trackingID只能来标识一次触摸动作的过程。

4、手势

            多点触摸指定的应用是创建手势动作， TOUCH和 WIDTH参数经常用来区别手指的压力和手指间的距离，另外 MINOR类的参数可以用来区别设备的接触面的大小（点接触还是面接触），ORIENTATION可以产生旋转事件。

5、在Linux内核支持的基础上，Android在其2.0源码中加入多点触摸功能（android4.0中间层有所不同）

            由此触摸屏在Android的frameworks被完全分为2种实现途径：单点触摸屏的单点方式，多点触摸屏的单点和多点方式。

             在Linux的input.h中，多点触摸功能依赖于以下几个主要的软件位：

在Android中对应的软件位定义在RawInputEvent.java中：

    在Android中，多点触摸的实现方法在具体的代码实现中和单点是完全区分开的。在Android代码的EventHub.cpp中，单点屏和多点屏由如下代码段来判定：

                我们知道，在触摸屏驱动中，通常在probe函数中会调用input_set_abs_params给设备的input_dev结构体初始化，这些input_dev的参数会在Android的EventHub.cpp中被读取。如上可知，如果我们的触摸屏想被当成多点屏被处理，只需要在驱动中给input_dev额外增加以下几个参数即可：

               由于多点触摸技术需要采集到多个点，然后再一起处理这些点，所以在软件实现中需要保证每一波点的准确性和完整性。因此，Linux内核提供了input_mt_sync（struct input_dev * input）函数。在每波的每个点上报后需要紧跟一句input_mt_sync（），当这波所有点上报后再使用input_sync（）进行同步。