Alan Stern <[email protected]> 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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
