需要帮助在共享I2C GPIO中断(linux)上处理多个共享ARM9 MAX3107芯片

Question

我们的团队正在使用嵌入式处理器(Phytec LPC3180，ARM9)。我们在LPC3180的一条I2C总线上设计了一个包含4个MAX3107串口芯片的电路板。如果重要的是，我们运行的是内核2.6.10，这是该处理器可用的最新版本(对该产品的支持不是很好；我们必须开发或修复Phytec提供的许多驱动程序，Phytec似乎没有兴趣为该产品升级linux代码(尤其是内核版本)。这太糟糕了，因为LPC3180是一个很好的设备，特别是在不需要以太网并且实际上不想要以太网的低功率嵌入式产品的环境中(由于以太网控制器芯片的相关功耗)。现在安装的处理程序(由其他人开发)基于上半个处理程序和下半个工作队列方法。

当I2C总线上的四个设备(MAX3107 UART芯片)中的一个接收到字符时，它会产生一个中断。所有四个MAX3107芯片的中断线是共享的(开漏下拉)，并且该线连接到3180的配置为电平中断的GPIO引脚。当3017中的一个产生中断时，运行一个处理程序，该处理程序执行以下处理(大致)：

spin_lock_irqsave();
disable_irq_nosync(irqno);
irq_enabled = 0;
irq_received = 1;
spin_unlock_irqrestore()
set_queued_work();  // Queue up work for all four devices for every interrupt
                    // because at this point we don't know which of the four
                    // 3107's generated the interrupt
return IRQ_HANDLED;

请注意，这也是我觉得有点麻烦的地方，在离开上面的代码之前没有重新启用中断。相反，驱动程序是这样编写的，即中断由下半个工作队列任务重新启用(使用"enable_irq(LPC_IRQ_LINE)函数调用“)。由于工作队列任务不在中断上下文中运行，我相信它们可能会休眠，我认为这对于中断处理程序来说不是一个好主意。

上述方法的基本原理如下: 1.如果四个MAX3107通用异步收发器芯片中的一个接收到字符并生成中断(例如)，则中断处理程序需要找出四个I2C设备中的哪一个实际导致了中断。然而，显然，不能从上半部分中断处理程序的上下文中读取I2C设备，因为I2C读取可以休眠，这被认为不适合中断处理程序的上半部分。2.解决上述问题(即哪个设备引起了中断)所采用的方法是使中断被禁用并退出上半部分处理程序，之后非中断上下文码可以查询I2C总线上的四个设备中的每一个，以找出哪个设备接收了字符(并因此产生了中断)。3.一旦下半处理程序找出哪个设备产生了中断，下半代码就禁用该芯片上的中断，这样它就不会重新触发到LPC3180的中断线。这样做之后，它读取串行数据并退出。

这里的主要问题似乎是无法从中断处理程序的上半部分中查询四个MAX3107通用异步收发器芯片。如果上半部分在返回之前简单地重新启用中断，这将导致相同的芯片再次生成中断，导致，我认为，导致上半部分禁用中断，调度下半部分工作队列并禁用中断的情况，结果发现自己回到了相同的位置，因为在下半部分代码到达引起中断的芯片之前，另一个中断已经发生，依此类推……

任何与这个驱动程序打交道的建议都将非常感谢。我真的不喜欢允许中断在驱动程序的上半部分被禁用，但在存在上半部分驱动程序代码之前不重新启用的想法。这看起来并不安全。

谢谢,

吉姆

PS:在我的阅读中，我发现线程中断是处理上述需求的一种手段(至少这是我对http://lwn.net/Articles/302043/等网站文章的理解)。我不确定Phytec提供的2.6.10内核是否包含线程中断函数。我打算在接下来的几天里调查这件事。

Answer 1

中断是启用和禁用的，因为我们使用基于级别的中断，而不是基于边沿的中断。其后果在驱动程序代码头中有明确的解释，Jim。

需要基于电平的中断，以避免在一个UART到达另一个UART之后立即到达另一个UART的字符丢失边缘中断:服务第一个有效地消除了第二个，因此第二个字符将丢失。事实上，这正是该驱动程序的初始边缘中断版本在执行>1 UART时发生的情况。

当前方案是否存在观察到的失败？

致敬，驱动程序的作者(其他人)