linux-kernel - request_threaded_irq 的 "handler function"中的 I2c 读取和写入操作如何影响整个驱动程序。？

Question

我有一个驱动程序代码，其处理函数和 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 上下文中的“处理程序 fn”是否在禁用中断的情况下运行)

请为上述情况提供一个好的和最佳的解决方案。

提前致谢。

Answer 1

I2C read/write transfers are NOT deterministic.

该协议(protocol)允许外围从属 IC 执行 clock stretching从而允许他们“持有”主人，直到他们准备好。然而，这不是一种常见的情况，因此每次 I2C 传输通常在大多数时间都在预定的时间间隔内完成。但是，这不是保证，因此在一个 ISR 中执行多个 I2C 传输不是一个好主意。

这link包含有关线程 irq 的基础知识及其正确用法的很好的解释。

---

上述场景的优化设计？

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

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

ISR代码:
1. 在 ISR 中，调用 disable_irq() 以防止进一步的中断。
2.安排一个bottom half handler function(workqueue是个不错的选择)。
3. 从 ISR 返回 IRQ_HANDLED。

下半部分处理程序代码:
4. 执行 I2C 传输。
5.调用enable_irq()并退出。

---

注意:
实现相同设计的另一种方法是使用不带 ISR 的线程中断。这实现了与上述设计相同的效果，并且无需在代码中单独定义/初始化/清理 bottom-half 处理程序。

在this approach one会将所有 I2C 读/写代码放在 IRQ thread function 中 并将其与 handler = NULL 一起传递给 request_threaded_irq()，即空 ISR。