On Tue, Dec 30, 2014 at 10:16:39AM -0500, Alan Stern wrote: > On Tue, 30 Dec 2014, Peter Chen wrote: > > > On Mon, Dec 29, 2014 at 10:44:28AM -0500, Alan Stern wrote: > > > On Mon, 29 Dec 2014, Peter Chen wrote: > > > > > > > For chipidea, its resume sequence is not-EHCI compatible, see > > > > below description for FPR at portsc. So in order to send SoF in > > > > time for remote wakeup sequence(within 3ms), the RUN/STOP bit must > > > > be set before the resume signal is ended. > > > > > > > > Force Port Resume - RW. Default = 0b. > > > > 1= Resume detected/driven on port. > > > > 0=No resume (K-state) detected/driven on port. > > > > Host mode: > > > > Software sets this bit to one to drive resume signaling. The Controller sets this bit to '1' if > > > > a J-to-K transition is detected while the port is in the Suspend state. When this bit > > > > transitions to a '1' because a J-to-K transition is detected, the Port Change Detect bit in > > > > the USBSTS register is also set to '1'. This bit will automatically change to '0' after the > > > > resume sequence is complete. This behavior is different from EHCI where the controller > > > > driver is required to set this bit to a '0' after the resume duration is timed in the driver. > > > > Note that when the controller owns the port, the resume sequence follows the defined > > > > > > > > sequence documented in the USB Specification Revision 2.0. The resume signaling > > > > (Full-speed 'K') is driven on the port as long as this bit remains a '1'. This bit will remain > > > > a '1' until the port has switched to idle. Writing a '0' has no affect because the port > > > > controller will time the resume operation, clear the bit and the port control state switches > > > > to HS or FS idle. > > > > This field is '0' if Port Power(PP) is '0' in host mode. > > > > > > > > This bit is not-EHCI compatible. > > > > > > If you really want to do this, go ahead. But see below. > > > > > > > Any other solutions for this (Let the SoF send in time within 3ms after resume > > signal has ended)? > > No, I don't have any good solutions. What this patch does isn't > suitable for EHCI controllers in general, because it disobeys section > 4.3 of the EHCI spec: > > When system software intends to suspend the entire bus, it should > selectively suspend all enabled ports, then shut off the host > controller by setting the Run/Stop bit in the USBCMD register > to a zero. The EHCI module can then be placed into a lower > device state via the PCI power management interface (See > Appendix A). > > With this patch, the Run/Stop bit gets set back to 1. > > When a wake event occurs the system will resume operation and > system software will eventually set the Run/Stop bit to a one > and resume the suspended ports. Software must not set the > Run/Stop bit to a one until it is confirmed that the clock to > the host controller is stable. > > With this patch, the Run/Stop bit remains equal to 1 even while the > clock to the host controller is turned off. > > The only solution I can think of is not very satisfactory. Suppose the > controller doesn't send any SoF packets within 3 ms of getting a wakeup > signal. Then the device will go back into suspend. Later on, when the > controller starts running, the hub driver will see that the device > requested a wakeup and will resume the device. Thanks, Alan. If the roothub will send resume before sending SoF, it should be ok, I just remembered I had seen "disconnect" before due to host send SoF to suspended device, will check it again. > > > > > + tmp = ehci_readl(ehci, &ehci->regs->command); > > > > + tmp |= CMD_RUN; > > > > + ehci_writel(ehci, tmp, &ehci->regs->command); > > > > > > At this point, the bus isn't suspended any more. It is running. > > > > > > > The bus state is 'J' since the portsc.suspendM = 1, so the bus is > > suspended, correct? > > True, no packets are being sent out to the bus. But the circuitry in > the EHCI controller is running, generating SoF packets every 125 us > (even though they don't get sent anywhere). > It needs PHY is in active mode, otherwise, there is no 480M for USB2, and the PHY is usually in suspend mode after controller enters suspend. -- Best Regards, Peter Chen -- 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
