[PATCH 10/12] irq: add comment about overall design of lost/spurious IRQ handling

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Tejun Heo
Date: Sunday, June 13, 2010 - 8:31 am

Give a general overview of the facility at the top of file and add
copyright notice.

Signed-off-by: Tejun Heo <tj@kernel.org>
---
 kernel/irq/spurious.c |   74 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 73 insertions(+), 1 deletions(-)

diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
index 2d92113..329555f 100644
--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
@@ -2,8 +2,66 @@
  * linux/kernel/irq/spurious.c
  *
  * Copyright (C) 1992, 1998-2004 Linus Torvalds, Ingo Molnar
+ * Copyright (C) 2010            SUSE Linux Products GmbH
+ * Copyright (C) 2010            Tejun Heo <tj@kernel.org>
  *
- * This file contains spurious interrupt handling.
+ * There are two ways interrupt handling can go wrong - too few or too
+ * many.  Due to misrouting or other issues, sometimes IRQs don't
+ * reach the driver while at other times an interrupt line gets stuck
+ * and a continuous spurious interrupts are generated.
+ *
+ * This file implements workaround for both cases.  Lost interrupts
+ * are handled by IRQ expecting and watching, and spurious interrupts
+ * by spurious polling.  All mechanisms need IRQF_SHARED to be set on
+ * the irqaction in question.
+ *
+ * Both lost interrupt workarounds require cooperation from drivers
+ * and can be chosen depending on how much information the driver can
+ * provide.
+ *
+ * - IRQ expecting
+ *
+ *   IRQ expecting is useful when the driver can tell when IRQs can be
+ *   expected; in other words, when IRQs are used to signal completion
+ *   of host initiated operations.  This is the surest way to work
+ *   around lost interrupts.
+ *
+ *   When the controller is expected to raise an IRQ, the driver
+ *   should call expect_irq() and, when the expected event happens or
+ *   times out, unexpect_irq().  IRQ subsystem polls the interrupt
+ *   inbetween.
+ *
+ *   As interrupts tend to keep working if it works at the beginning,
+ *   IRQ expecting implements "verified state".  After certain number
+ *   of successful IRQ deliveries, the irqaction becomes verified and
+ *   much longer polling interval is used.
+ *
+ * - IRQ watching
+ *
+ *   This can be used when the driver doesn't know when to exactly
+ *   expect and unexpect IRQs.  Once watch_irq() is called, the
+ *   irqaction is slowly polled for certain amount of time (1min).  If
+ *   IRQs are missed during that time, the irqaction is marked and
+ *   actively polled; otherwise, the watching is stopped.
+ *
+ *   In the most basic case, drivers can call this right after
+ *   registering an irqaction to verify IRQ delivery.  In many cases,
+ *   if IRQ works at the beginning, it keeps working, so just calling
+ *   watch_irq() once can provide decent protection against misrouted
+ *   IRQs.  It would also be a good idea to call watch_irq() when
+ *   timeouts are detected.
+ *
+ * - Spurious IRQ handling
+ *
+ *   All IRQs are continuously monitored and spurious IRQ handling
+ *   kicks in if there are too many spurious IRQs.  The IRQ is
+ *   disabled and the registered irqactions are polled.  The IRQ is
+ *   given another shot after certain number IRQs are handled or an
+ *   irqaction is added or removed.
+ *
+ * All of the above three mechanisms can be used together.  Spurious
+ * IRQ handling is enabled by default and drivers are free to expect
+ * and watch IRQs as they see fit.
  */
 
 #include <linux/jiffies.h>
@@ -17,6 +75,20 @@
 
 #include "internals.h"
 
+/*
+ * I spent quite some time thinking about each parameter but they
+ * still are just numbers pulled out of my ass.  If you think your ass
+ * is prettier than mine, please go ahead and suggest better ones.
+ *
+ * Most parameters are intentionally fixed constants and not
+ * adjustable through API.  The nature of IRQ delivery failures isn't
+ * usually dependent on specific drivers and the timing parameters are
+ * more about human perceivable latencies rather than any specific
+ * controller timing details, so figuring out constant values which
+ * can work for most cases shouldn't be too hard.  This allows tighter
+ * control over polling behaviors, eases future changes and makes the
+ * interface easy for drivers.
+ */
 enum {
 	/* irqfixup levels */
 	IRQFIXUP_SPURIOUS		= 0,		/* spurious storm detection */
-- 
1.6.4.2

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCHSET] irq: better lost/spurious irq handling, Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 01/12] irq: cleanup irqfixup, Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 04/12] irq: kill IRQF_IRQPOLL, Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 06/12] irq: implement irq_schedule_poll(), Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 07/12] irq: improve spurious IRQ handling, Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 10/12] irq: add comment about overall design of los ..., Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Sun Jun 13, 8:31 am)
[PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Sun Jun 13, 8:31 am)
Re: [PATCH 12/12] usb: use IRQ watching, Greg KH, (Mon Jun 14, 2:41 pm)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Mon Jun 14, 2:52 pm)
Re: [PATCH 12/12] usb: use IRQ watching, Greg KH, (Mon Jun 14, 3:11 pm)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Mon Jun 14, 3:19 pm)
Re: [PATCH 02/12] irq: make spurious poll timer per desc, Konrad Rzeszutek Wilk, (Mon Jun 14, 10:10 pm)
Re: [PATCH 12/12] usb: use IRQ watching, Kay Sievers, (Tue Jun 15, 3:30 am)
Re: [PATCH 12/12] usb: use IRQ watching, Jean Delvare, (Tue Jun 15, 4:05 am)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Tue Jun 15, 4:20 am)
Re: [PATCH 12/12] usb: use IRQ watching, Kay Sievers, (Tue Jun 15, 6:30 am)
Re: [PATCH 12/12] usb: use IRQ watching, Kay Sievers, (Tue Jun 15, 6:36 am)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Tue Jun 15, 10:36 am)
Re: [PATCH 06/12] irq: implement irq_schedule_poll(), Jonathan Corbet, (Tue Jun 15, 10:40 am)
Re: [PATCH 12/12] usb: use IRQ watching, Greg KH, (Tue Jun 15, 10:47 am)
Re: [PATCH 06/12] irq: implement irq_schedule_poll(), Tejun Heo, (Tue Jun 15, 10:51 am)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Tue Jun 15, 10:52 am)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Mon Jun 21, 6:51 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Mon Jun 21, 6:52 am)
Re: [PATCH 12/12] usb: use IRQ watching, Greg KH, (Mon Jun 21, 1:27 pm)
Re: [PATCH 12/12] usb: use IRQ watching, Tejun Heo, (Tue Jun 22, 12:32 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Thu Jun 24, 5:22 pm)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Fri Jun 25, 12:44 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Fri Jun 25, 2:48 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Fri Jun 25, 2:51 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Fri Jun 25, 8:45 pm)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Fri Jun 25, 8:52 pm)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Sat Jun 26, 1:31 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Sat Jun 26, 2:16 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Sat Jun 26, 2:44 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Fri Jul 2, 7:41 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Fri Jul 2, 7:53 am)
[GIT PULL] irq: better lost/spurious irq handling, Tejun Heo, (Fri Jul 2, 7:59 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Sat Jul 10, 3:06 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Wed Jul 14, 12:58 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Tejun Heo, (Wed Jul 14, 2:26 am)
Re: [PATCH 11/12] libata: use IRQ expecting, Jeff Garzik, (Tue Jul 27, 10:37 am)