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 7.1.7.7 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 http://vger.kernel.org/majordomo-info.html
