On Thu, 12 Apr 2012, Chen Peter-B29397 wrote: > > Good patch, Alan. Only one thing is that it needs a delay between > > re-suspend, and send resume again. (Sorry, I can't find the detail > > delay time between suspend and resume signal at usb2.0 spec). > > > > I will test this patch, and give you a response. > > > > I have some problems with patch, and the SOF isn't out after the second resume has finishes. > I will go on debugging this problem next week. > > I think this patch has some risks, and it needs both host and device's behavior to be correct > after 2 times suspend/resume for every remote wakeup occurrence. Remote wakeup occurs: > > - Device remote wakeup signal at both autosuspend/system suspend situation > - Device connect/disconnect with/without HUB cases at both autosuspend/system suspend situation. > > Esp for 3G/LTE modem cases, if it supports autosuspend at runtime, remote wakeup occurs very frequently. You're right. And after thinking about this some more, I decided that your approach of turning on CMD_RUN during controller suspend is the easiest and best approach. Two things: Your controller-resume routine should also call usb_hcd_resume_root_hub. Did you say that you're doing this already? Otherwise you could end up with the controller on and sending out SOF packets while the root hub remains suspended indefinitely, wasting power. The other issue has to do with CMD_ASE and CMD_PSE bits. They must be off when you enable CMD_RUN! Otherwise the controller would try to access the data structures for the schedules at a bad time. Normally ehci-hcd does try to make sure the CMD_ASE and CMD_PSE are off when the root hub is suspended. But some controllers (the Cell chip on the PS3) don't always turn these bits off when they are supposed to. Therefore this technique of enabling CMD_RUN during controller suspend should be used only when it is necessary, that is, only with the Synopsis-based controllers. Also, it's not clear that all controllers will continue to work correctly if CMD_RUN is on when they are put into low power. That's another reason for doing this only when necessary. 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