request_threaded_irq 的“处理函数”中的 I2c 读取和写入操作如何影响整个驱动程序？

我有一个带有 request_threaded_irq 的处理函数和线程函数的驱动程序代码，与此类似：

irq-handler fn()
{
      /*disable device interrupt*/
      i2c read from register;
      set disable bit to client-device-interrupt 
      i2c write back;
      return IRQ_WAKe_THREAD;
}



irq-thread fn()
{
      i2c read from register;
      ....
      ....
      /*enable device interrupt*/
      i2c read from register;
      set enable bit to client-device-interrupt 
      i2c write back;
      /*Rest of the operation*/
      ..........
      ..........
      return IRQ_HANDLED;
}

我对上述实施没有什么疑问。

1. “handler fn”中的 2 i2c 操作会花费大量时间吗？

2. 我是否需要在“handler fn”原子中进行位操作？

3. 我是否应该将“启用设备中断”之前执行的操作从“线程 fn”移动到“处理程序 fn”（这将花费我 4 个以上的 i2c 操作和一位操作）？ - 原因是，按照上面的代码实现，我可能会错过中断。

4. 如果我这样做（按照问题 3）。它如何影响其他设备中断。（因为我有一个基本疑问：硬 IRQ 上下文中的“handler fn”是否在禁用中断的情况下运行)

请为我提供针对上述情况的良好且最佳的解决方案。

提前致谢。

I2C 读/写传输不是确定性的。

该协议允许外围从 IC 执行时钟拉伸 http://en.wikipedia.org/wiki/I%C2%B2C#Clock_stretching_using_SCL从而允许他们“抓住”主人直到他们准备好。 然而，这不是常见情况，因此每个 I2C 传输通常在大多数情况下以预定间隔完成。然而，这并不能保证，因此在 ISR 中执行多次 I2C 传输并不是一个好主意。

This link http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-March/001118.html包含关于线程 irq 的基础知识及其正确用法的很好的解释。

上述场景的最佳设计？

使用线程中断处理程序方法不会有太多好处，因为尝试启用/禁用设备上的中断会增加延迟。

在您当前的情况下（来自单个设备的单个中断），可以坚持常规request_irq()注册中断服务程序（ISR）。

ISR code :
1. 在 ISR 中，调用disable_irq()以防止进一步的中断。
2. 安排一个下半部分处理函数（工作队列是一个不错的选择）。
3. 返回IRQ_HANDLED来自ISR。

下半部分处理程序 code :
4. 执行 I2C 传输。
5. 打电话enable_irq()并退出。

NOTE :
实现相同设计的另一种方法是使用没有 ISR 的线程中断。这实现了与上述设计相同的效果，并且无需在代码中单独定义/初始化/清理下半部处理程序。

In 这种方法一 http://lxr.free-electrons.com/source/drivers/input/touchscreen/qt602240_ts.c?v=2.6.38#L1283将把所有 I2C 读/写代码放在IRQ线程函数 http://lxr.free-electrons.com/source/drivers/input/touchscreen/qt602240_ts.c?v=2.6.38#L677并将其传递给request_threaded_irq()随着handler = NULL即空 ISR。