RE: Remote wakeup timing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
> 
> 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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux