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. > > > + 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). 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
