> > > > 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? > I will post this question to our IC guys. > > 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 only individual port is suspend, but bus does not go to suspend, it is no problem as the controller is at run mode and the PHY is active, this resume signal is just port change for hub. We are standard 2.0 hosts which follows USB 2.0 spec, we can't forbid device to do something which not breaks spec, like sending resume 20ms later after bus suspend. > > - 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? > You mean what actually happening? We can use g_zero at another board to send resume at anytime once receiving suspend to emulate remote wakeup case. I have heard from one 3G module vendor, that the minimize time between receiving suspend to sending resume is 20ms (or 50ms, I can't remember clearly). Whether device sends resume depends on if there is coming data at 3G network. > 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
