Thread (43 messages) 43 messages, 8 authors, 2015-06-01

Re: [PATCH 2/5] PM / Wakeirq: Add automated device wake IRQ handling

From: Tony Lindgren <tony@atomide.com>
Date: 2015-05-19 15:15:15
Also in: linux-omap, linux-pm, lkml

* Rafael J. Wysocki [off-list ref] [150519 06:40]:
On Monday, May 18, 2015 04:44:01 PM Tony Lindgren wrote:
quoted
+/**
+ * handle_threaded_wake_irq - Handler for dedicated wake-up interrupts
+ * @irq: Device dedicated wake-up interrupt
+ * @_wirq: Wake IRQ data
+ *
+ * Some devices have a separate wake-up interrupt in addition to the
+ * device IO interrupt. The wake-up interrupts signal that the device
+ * should be woken up from a idle state. This handler uses device
+ * specific pm_runtime functions to wake the device and then it's
+ * up to the device to do whatever it needs to. Note as the device
+ * may need to restore context and start up regulators, we use a
+ * threaded IRQ.
+ *
+ * Also note that we are not resending the lost device interrupts.
+ * We assume that the wake-up interrupt just needs to wake-up the
+ * device, and the device pm_runtime_resume() can deal with the
+ * situation.
+ */
+static irqreturn_t handle_threaded_wake_irq(int irq, void *_wirq)
+{
+	struct wake_irq *wirq = _wirq;
+
+	/* We don't want RPM_ASYNC or RPM_NOWAIT here */
+	return pm_runtime_resume(wirq->dev) ? IRQ_NONE : IRQ_HANDLED;
There are various reasons why pm_runtime_resume() may return error codes and
some of them don't mean that the interrupt was not legitimate.

Moreover, it returns 1 if the device is already active, in which case the above
check won't do any good to us.
OK yeah that check won't work then.
 
Why not to return IRQ_HANDLED unconditionally from here?
OK

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help