ARM GIC中断饥饿

Question

不确定是否有类似的问题。我试图重新阅读但无法找到任何内容，所以就在这里。

在我使用ARM Cortex-A9（带有GIC的双核）的裸机应用程序中，一些中断源是4个FPGA中断（让我们说IRQ ID 58,59,60,61）同样的优先级和想法是所有同时在运行时连续触发。我可以说中断处理程序的资格可能很长，但不会很长。

所有中断都会触发并被GIC检测到，所有中断都被标记为PENDING。问题是，只有两个较高的ID中断（58,59）由CPU处理，使另外两个中断。完成58或59后，它们的源将再次触发并反复占用CPU。我的其他中断无限期地被饿死了。

我优先玩，将更高的中断分配到60和61.果然，60和61触发并由CPU处理，但58和59被饿了。所以这真的是一个饥饿问题。

有没有办法离开这里，以便其他两个仍然会根据其触发率进行处理？

Answer 1

假设GIC实现是ARM的设计之一，那么相同优先级的多个中断的仲裁方案固定为“发送编号最小的一个”，所以如果你希望它可以改为某种圆形-robin scheme你可能运气不好。

那就是说，如果这些中断或多或少地永久断言并且你背对背，那么这表明你可能不需要使用中断，或者至少是你的代码设计不合适。根据任务的确切性质，以下是我要考虑的一些想法：

• 只需依次循环运行每个设备的连续轮询循环。如果是句点，当每个设备可能不需要服务并且它不是直截了当时，保留一个简单的中断处理程序，它只是自动设置标志/序列号/等。通知循环谁准备好了。
• 处理一个核心上的所有中断，并处理另一个核心上的实际处理。处理程序只是抓取必要的数据，将其填入队列，并尽快返回，而另一个人只是稳稳地咀嚼队列。
• 如果捕获每个中断的重要性不仅仅是平均每个中断的“足够”，那么在处理完每个中断后，将每个中断禁用一段合适的超时。或者，通过一次只启用一个循环调度来破解您自己的循环调度，并且处理程序重新启用 next 中断而不是刚刚执行的中断。

Answer 2

  

在我的裸机应用程序中使用ARM Cortex-A9（双核与GIC）......

  

有没有办法离开这里，以便其他两个仍然会根据其触发率进行处理？

当然有很多方法。

1. 你有一个双CPU，所以你可以将一套路由到每个CPU; 58/59到CPU0和60/61到CPU1。目前尚不清楚如何处理分配器和每CPU接口的事情。
2. A ^nd 方式是只读取60/61的58/59处理程序中的状态并完成工作。即，您始终可以从IRQ处理程序中读取另一个中断的状态。
3. 您还可以在确认原始来源之前，为IRQ开始时记录的每个待处理中断提供服务。 ＆＃39; 2＆＃39;的变体在IRQ控制器层实现。

我相信大多数这些解决方案都可以避免不必要的上下文保存/恢复，并且还应该更高效。

当然，如果你要求CPU做的工作超出其能力，那么优先事项并不重要。问题可能是您的代码效率不高;裸机中断基础设施或FPGA IRQ处理程序。 FPGA到CPU接口的设计很可能不是很好。您可能需要在FPGA中添加FIFO以缓冲数据，以便CPU可以一次处理更多数据。我和几位FPGA设计师合作过。它们具有很大的灵活性，通常如果你要求能使IRQ处理程序更有效的东西，它们就可以实现它。