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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
