根据上半部和下半部的引导线，当任何中断到来时，它由两半处理。所谓的上半部分是实际响应中断的例程 - 您使用request_irq注册的中断。下半部分是一个例程，由上半部分安排，以便在更安全的时间执行。上半部分处理程序和下半部分之间的最大区别在于，在执行下半部分期间启用了所有中断 - 这就是它在更安全的时间运行的原因。在典型情况下，上半部分将设备数据保存到特定于设备的缓冲区，调度其下半部分并退出：此操作非常快。然后，下半部分执行所需的任何其他工作，例如唤醒进程，启动另一个I / O操作，等等。此设置允许上半部分在下半部分仍在工作时服务新中断。
但是如果中断在更安全的时间由下半部分处理，那么逻辑上当中断到来时它必须等到下半部分找到一些更安全的时间来执行将限制系统的中断并且必须等到中断处理，例如：如果我正在进行项目，当温度高于特定限制时提供LED闪烁指示，那么如果在某些安全时间可用时完成中断处理（根据下半部概念），则闪烁操作将被延迟....请澄清我怀疑所有的中断是如何处理的？
当使用上半部/下半部中断架构时，通常存在高优先级中断处理线程。
此中断处理线程的优先级高于系统中的其他线程（某些供应商SDK为此目的指定“中断”优先级）。通常有一个队列，当队列中没有工作时线程会休眠。该线程/队列的设计使得可以从中断上下文安全地添加工作。
当调用上半部分处理程序时，它将处理硬件操作，然后将下半部分处理程序添加到中断队列。上半部分处理程序返回并退出中断上下文。然后，操作系统将检查下一个运行的线程。因为中断线程有可用的工作，并且因为它是最高优先级，所以它将在下一次运行。这可以最大限度地减少您担心的延迟。
自然会有一些延迟抖动，因为队列中可能有其他中断在LED之前发射（在您的示例中）。根据应用和实时要求，有不同的解决方案。一种是基于中断优先级来排序队列。这会在排队操作时产生额外的成本，但它也可以确保您的中断将按优先级处理。对于关键延迟，另一个选择是在上半部分中断处理程序中完成所有工作。
记住这种架构的目的很重要：
我们仍然希望我们的下半部分处理程序尽快运行以减少延迟，因此当您说“等待更安全的时间”时，这意味着“在中断上下文之外”。
如果眨眼操作太重要而不能延迟，你可以把它放到上半部分，可能根本没有下半部分。但是，取决于您在上半部分的操作，它可能会也可能不会影响系统性能。
我建议你为这两种情况编写代码并执行一些分析