Re: The corner case for USB remote wakeup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Tue, 24 Apr 2012, Chen Peter-B29397 wrote:

> Hi Alan,
> Currently, more and more USB interface 3G modules begin to use at embedded
> device, most of them support USB remote wakeup.
> According to USB2.0 spec Resume
> A device with remote wakeup capability may not generate resume signaling
> unless the bus has been continuously in the Idle state for 5 ms (TWTRSM).
> That is to say, the remote wakeup featured device may generate resume
> signal after 5ms later of USB bus suspend (Full speed J).
> Some controllers may have problems if there
> is a resume signal on the port as well as the PHY is trying to enter low
> power mode. In order to avoid this corner case, the time between set bus suspend 
> (portsc.suspendM) and set PHY to low power mode should be within 5ms.
> At current EHCI code, only some Intel controllers (has_hostpc) set PHY to low power
> mode after bus suspend(but they are also larger than 5ms between bus suspend and
> PHY enters low power mode).

What happens if a wakeup request arrives after the PHY is in low-power 
mode?  Why doesn't that cause the same sort of problem?

Or to put it another way, why doesn't the PHY react in the same way to 
a wakeup request, regardless of whether it is entering low-power mode 
or already in low-power?

> My questions are:
> - Such resume signal coming and PHY entering low power mode case should be considered
> by SoC design(Controller skips resume signal, until PHY has entered low power mode)?
> or Software needs to make sure timing (time between set portsc.suspendM and PHY enters
> low power mode should less than 5ms)?

It's very difficult for a general-purpose operating system like Linux
(without the RT patch set) to guarantee that a certain action will be
taken within a specific time limit.  If the delay between port suspend
and putting the PHY in low power needs to be less than 5 ms then it
ought to be handled in hardware, not in software.

But even that won't solve your problem, because Linux can suspend
individual ports long before suspending the entire USB bus.  What
happens if a port was suspended 2 minutes ago and you want to set the 
PHY to low power now?  There's no way to prevent the device on that 
port from sending a wakeup request at a bad time.

> - If some controllers already have above concurrency issue, how to work around this?
> Is it reasonable to put PHY low power mode interface at EHCI code?

As explained above, this problem cannot be prevented.

Have you observed this actually happening?  Do you have devices that 
send a wakeup request only a few milliseconds after being suspended?

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

B and H Foto and Electronics Corp.

[Linux Media]     [Video for Linux]     [Linux Input]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]     [More Archives]

Add to Google Powered by Linux