lkml.org 
[lkml]   [2015]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/5] PM / Wakeirq: Add automated device wake IRQ handling
* Rafael J. Wysocki <rjw@rjwysocki.net> [150519 06:40]:
> On Monday, May 18, 2015 04:44:01 PM Tony Lindgren wrote:
> > +/**
> > + * 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


\
 
 \ /
  Last update: 2015-05-19 18:01    [W:0.615 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site