Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, October 06, 2010, Alan Stern wrote:
> On Tue, 5 Oct 2010, Kevin Hilman wrote:
> 
> > Alan Stern <stern@rowland.harvard.edu> writes:
> > 
> > > On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
> > >
> > >> > > In my opinion the _irq operations should really be one-shot, without
> > >> > > any looping, waking up parents etc.  I mean, if the parent is not RPM_ACTIVE,
> > >> > > the _irq resume should immediately fail and analogously for the _irq
> > >> > > suspend.  And so on.  As simple as reasonably possible.
> > >> > 
> > >> > But what if the device's own status is currently SUSPENDING or
> > >> > RESUMING?  Do you want to fail when that happens, instead of waiting
> > >> > for the concurrent operation to finish?
> > >> 
> > >> Yes.  IMO an _irq() suspend should only be allowed if the status is RPM_ACTIVE
> > >> and an _irq() resume should fail if the status is not RPM_SUSPENDED.  The
> > >> error code returned should depend on the situation, though.
> > >> 
> > >> > There's no way to prevent this
> > >> > on SMP systems, because a wakeup request can arrive while a
> > >> > software-initiated resume is in progress.
> > >> 
> > >> I know that. :-)
> > >
> > > I suspect Kevin will not want to live with this restriction, but I'd
> > > like to hear from him.  Kevin?
> > 
> > [ Apologies for the delays... I've been running around preparing OMAP PM
> >   stuff for the upcoming merge window. ]
> > 
> > I think I can live with the above restrictions (the _irq methods failing
> > unless they can immediately run.)  For the rare corner cases I've
> > currently run into, this will work fine as they happen because of a
> > wakeup IRQ, where we know the device is RPM_SUSPENDED.
> 
> Then what will the driver do if it gets a wakeup IRQ but it can't
> resume the device because some other thread is in the middle of a
> suspend or resume?

Queue up a resume request and return.

Thanks,
Rafael