On Tue, 10 Apr 2012, Chen Peter-B29397 wrote: > > Hi Alan, > > > > In order to support remote wakeup well, we need to take some timing > > issues > > into consideration. For example, after resuming signal, the SOF must be > > sent by host within 3ms, or the device will suspend again, in that case, > > the device may be taken as disconnection once host sends SOF. Why would the host think the device had disconnected? Is this because the port is no longer suspended and has switched to its high-speed terminations, while the device is still using full-speed signalling? > > For some controllers, the SOF is controlled by usbcmd.rs, only > > usbcmd.rs=1, > > the host sends SOF. But according to ehci spec, the usbcmd.rs need to be > > clear > > after bus suspend. The host set usbcmd.rs again at bus resume, but bus > > resume > > routine may not be called with 20ms (Some controller will end resume > > signal > > automatically within a little more than 20ms), then the above problem > > occurs. So the problem is that some buggy controllers turn off the resume signal when they shouldn't. Don't chip designers realize that violating the spec is a bad idea? > > The usb_hcd_resume_root_hub is only called at PCD interrupt when > > usbcmd.rs=0, > > I would like to set usbcmd.rs as early as possible (at platform or > > controller > > code), but don't want break usb core. Current, my solution is run > > usb_hcd_resume_root_hub at controller code, and the PCD interrupt will be > > triggered later. Any risks for this solution, do you have any better > > suggestions? I don't like this approach. Even if the controller code calls usb_hcd_resume_root_hub, there's still no guarantee that ehci_bus_resume will run within 20 ms. System resume involves a lot of activity, and it may be a long time before a particular routine gets a chance to run. A better approach might be to have ehci_bus_resume check the port statuses before turning on CMD_RUN, and re-suspend any enabled port that isn't already suspended. Then when the controller starts sending SOF packets, the host shouldn't think the device had disconnected. Would that solve your problem? > Is it possible to use other conditions, like hcd->state == HC_STATE_SUSPENDED > to run usb_hcd_resume_root_hub at PCD interrupt? What's wrong with the existing condition (ehci->rh_state == EHCI_RH_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
