> > 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? > Host works at high speed mode, the high speed disconnect condition is differential voltage(dp/dm) larger than 625 mV. The device is still at full speed idle, so dp is 3v, but dm is pull down by host, and it is 0v. > > > 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? There are some bits' behavior at portsc are different with EHCI at Synopsys core(from chipidea's). > > > > 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. > In order to solve this problem, the current solution we use is set usbcmd.rs again at controller's suspend if there is a device at port and it is remote wakeup featured. If usbcmd.rs=1, the SOF will be sent out automatically once the resume signal has finished, and the device will work at high speed mode. So, it doesn't matter when the ehci_bus_resume is called. > 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)? > I mean at ehci_irq, if PCD interrupt occurs, it uses usbcmd.rs=0 to call usb_hcd_resume_root_hub, does it possible use some flags (ehci->rh_state == EHCI_RH_SUSPENDED or hcd->state == HC_STATE_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
