I2c如何在“处理程序功能"中进行读取和写入操作. request_threaded_irq的数量会整体上影响驱动程序. [英] How an I2c read as well as write operation in "handler function" of request_threaded_irq affects the driver as a whole.?

问题描述

我有一个驱动程序代码，具有与此类似的处理函数和线程函数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执行时钟延长从而允许他们握住"主人，直到他们准备好为止. 但是，这并非常见情况，因此每次I2C传输通常在大多数时间以预定间隔完成.但是，这并不是保证，因此在ISR中执行几次I2C传输也不是一个好主意.

此 链接 包含有关线程化irq的基本原理及其正确用法的很好的解释.

---

上述情况的最佳设计?

使用线程中断处理程序方法不会带来很多好处，因为尝试在设备上启用/禁用中断会增加延迟.

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

ISR 代码:
1.在ISR中，调用disable_irq()以防止进一步的中断.
2.安排下半部处理程序函数(工作队列是一个不错的选择).
3.从ISR返回IRQ_HANDLED.

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

---

注意:
实现相同设计的另一种方法是使用没有ISR的 threaded-irq .这样可以达到与上述设计相同的效果，并且无需在代码中单独定义/初始化/清除下半部处理程序.

在 中>这种方法 会将所有I2C读/写代码放在

Should I need to make bit manipulation in "handler fn" atomic?

Should I move the operation performed till "enable device interrupt" from "thread fn" to "handler fn"(this would cost me 4 more i2c operation and one bit manipulation exactly) ? - reason being chances are there that i can miss interrupt as per above code implementation.

If I do so(as per question 3). how does it affects the other device interrupts.(as I have a basic doubt whether "handler fn" in hard IRQ context operates with interrupts disabled)

Please provide me a good and optimum solution for the above scenario.

Thanks in advance.

解决方案

I2C read/write transfers are NOT deterministic.

The protocol allows peripheral slave ICs to perform clock stretching thereby allowing them to "hold" the master until they are ready. However this is NOT a common scenario and hence each I2C transfer usually completes in a pre-determined interval most of the time. However, it is NOT a guarantee, and hence NOT a good idea to perform several I2C transfers within an ISR.

This link contains a nice explanation about the fundamentals of threaded irqs and their proper usage.

---

Optimal design for the above scenario ?

Using threaded-interrupt handler approach will not have many benefits as attempting to enable/disable the interrupts on the device will add to the latency.

In your current scenario (single interrupt from single device), one can stick to the regular request_irq() to register an interrupt service routine(ISR).

ISR code :
1. In the ISR, call disable_irq() to prevent further interrupts.
2. Schedule a bottom half handler function (workqueue is a good choice).
3. Return IRQ_HANDLED from the ISR.

Bottom-half handler code :
4. Perform I2C transfers.
5. Call enable_irq() and exit.

---

NOTE :
Another way to implement the same design would be to use a threaded-irq without an ISR. This achieves the same as the above design and eliminates the need to define/initialise/cleanup the bottom-half handler separately in your code.

In this approach one would put all the I2C read/write code within the IRQ thread function and pass it to request_threaded_irq() along-with handler = NULL i.e. an empty ISR.

这篇关于I2c如何在“处理程序功能"中进行读取和写入操作. request_threaded_irq的数量会整体上影响驱动程序.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！