背光调节引发的中断问题

            曾经在调试背光代码时发现有时调节背光亮度时会出现紊乱，该亮的时候反而很暗,检查代码也没发现什么问题。后来经过查资料发现是系统中断破坏了脉冲发送个数（背光IC是单线调节，通过发送不同的脉冲来控制）。也就是脉冲没有按照预期的发送，被中断打断了。找到了原因，问题就好解决了。在发送脉冲时关中断，发送完毕后再打开中断，避免中断的干扰。具体函数介绍如下：
    在2.6内核中,可以通过下面两个函数中的其中任何一个关闭当前处理器上的所有中断处理，这两个函数定义在 <asm/system.h>中:
    void local_irq_save(unsigned long flags);
    void local_irq_disable(void);
    对 local_irq_save的调用将把当前中断状态保存到flags中，然后禁用当前处理器上的中断发送。注意, flags 被直接传递, 而不是通过指针来传递。 local_irq_disable不保存状态而关闭本地处理器上的中断发送; 只有我们知道中断并未在其他地方被禁用的情况下，才能使用这个版本。
    可通过如下函数打开中断:
    void local_irq_restore(unsigned long flags);
    void local_irq_enable(void);
    第一个版本将local_irq_save保存的flags状态值恢复, 而local_irq_enable无条件打开中断. 与 disable_irq不同, local_irq_disable不会维护对多次的调用的跟踪。 如果调用链中有多个函数需要禁止中断, 应该使用local_irq_save.
    在2.6内核, 没有方法全局禁用整个系统的所有中断。 内核开发者认为关闭所有中断的代价太高，因此没有必要提供这个能力。如果读者使用的老驱动程序调用了类似cli和sti这样的函数，为了该驱动程序能够在2.6下使用，则需要进行修改而使用正确的锁。
    in_interrupt()是判断当前进程是否处于中断上下文，这个中断上下文包括底半部和硬件中断处理过程，
函数实现：
     #define in_interrupt() ({ const int __cpu = smp_processor_id(); /
          (local_irq_count(__cpu) + local_bh_count(__cpu) != 0); })
判断中断计数和底半部计数是否〉0，如果只希望判断是否在硬件中断上下文，则可以使用：in_irq()。

在目前多处理器的时代，对中断的使用和控制尤为重要，否则将会出现意想不到的结果。