Re: [PATCH] usb: Add support for runtime power management of the hcd

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

[Sorry for the delayed response, I was distracted by the btusb regression
causing resume to fail on my box.]

On Tuesday 10 November 2009, Alan Stern wrote:
> On Tue, 10 Nov 2009, Matthew Garrett wrote:
> 
> > On Tue, Nov 10, 2009 at 02:08:01PM +0100, Oliver Neukum wrote:
> > 
> > > I was wondering because a tester has reported a race in ehci that
> > > can lead to a loss of wakeup events. Alan posted a patch to fix it.
> > > Does it cooperate with your patch?
> > 
> > Hm. I'll look into that.
> 
> There should not be any interaction.  That particular race occurs when
> the root hub is suspended, not when the controller is suspended.
> 
> 
> But this does raise an interesting point.  We do still have a race 
> between remote wakeup and system sleep.

We do to some extent.  There is the check in dpm_prepare() that will abort
system sleep transitions if run-time wake-up has been requested earlier,
but later requests will be discarded.

> Suppose we're in the middle of a system sleep transition, and device D
> (such as a USB root hub) has been suspended as part of the normal
> preparation.  But then D generates a remote wakeup IRQ.
> 
> D's driver will field the interrupt request and will call something
> like pm_request_resume(), to schedule a workqueue item for a runtime
> resume of D.  However, the runtime-PM workqueues are either frozen or
> in some other way prevented from doing anything while the system sleep
> transition is in progress.
> 
> Therefore the wakeup request will get lost.  The information is still
> present, in the form of a work_struct, but it won't get acted on until
> the system wakes up.  In particular, it won't prevent the sleep
> transition from completing and it won't cause the system to wake up
> immediately after going to sleep.
> 
> This suggests that pm_request_resume() should abort a sleep transition
> if one is already in progress.  Rafael, what do you think?

That's not an easy question, becuase there always will be a point after which
we can't handle a run-time resume request.  If we are deep enough into the
suspend process, we won't receive wakeup interrupts any more, at least on
some platforms.

Thanks,
Rafael