On Tue, Oct 09, 2012 at 11:03:47AM -0400, Alan Stern wrote:
> On Tue, 9 Oct 2012, Peter Chen wrote:
>
> > Hi Alan,
> >
> > When I try to optimize system resume time, I find bus resume routine
> > cost much time (> 20ms), even there is no device at any ports.
> > Let's take ehci bus resume as an example.
> >
> > 1. At ehci_bus_resume
> >
> > /* Some controller/firmware combinations need a delay during which
> > * they set up the port statuses. See Bugzilla #8190. */
> > spin_unlock_irq(&ehci->lock);
> > msleep(8);
> > spin_lock_irq(&ehci->lock);
> > Is it possible to add condition?
>
> If you can come up with a good condition, sure.
According to Bugzilla #8190, the port status is not correct during
the suspend, can we use this as condition?, But we may can't find the tester.
See below comment:
Comment #18 From Alan Stern 2007-03-14 13:42:40
Created an attachment (id=10761) [details]
Diagnose EHCI port resume
This is very bizarre. Here's the important part of the log, leaving out
everything except for port 3:
[ 0.971514] ehci_hcd 0000:00:1d.7: port 3 status1 1005
[ 0.991544] ehci_hcd 0000:00:1d.7: port 3 status2 1085
[ 0.991546] ehci_hcd 0000:00:1d.7: resume done
The status1 value should be 1085 and the status2 value should be 10c5, meaning
that the port was suspended at first but then the resume bit was turned on.
Instead the port was unsuspended at first and then somehow it got suspended!
That's why the scanner wasn't working; it was still suspended.
Try using this new patch and see if it makes any difference.
>
> > 2. At hcd_bus_resume
> > if (status == 0) {
> > /* TRSMRCY = 10 msec */
> > msleep(10);
> > This 10ms delay is needed when the device is connected and CONFIG_USB_SUSPEND
> > is not defined, can we add condition like:
>
> You should not depend on this. In the future, the delay will be needed
> even when CONFIG_USB_SUSPEND is defined.
>
> > if (status == 0) {
> > #ifndef CONFIG_USB_SUSPEND
> > if (no_device_on_port)
> > /* TRSMRCY = 10 msec */
> > msleep(10);
> > #endif
> > For the no_device_on_port, it needs to add flag at struct usb_hcd.
Sorry, should be if (device_on_port)
>
> In fact, with ehci-hcd this delay isn't needed at all.
> ehci_bus_resume() does its own 20-ms delay if there are any unsuspended
> enabled ports.
unsuspended enabled ports? According to my knowledge, only the port receives
remote-wakeup is unsuspended enabled port at that situation.
According USB Spec 2.0, ch7.1.7.7:
The USB System Software must provide a 10 ms resume recovery time (TRSMRCY)
during which it will not attempt to access any device connected to the
affected (just-activated) bus segment.
The TRSMRCY is needed after resume signal ends up, if the port is not
companion port, there is no 20ms delay at ehci_bus_resume.
If CONFIG_USB_SUSPEND is defined, and ehci->no_selective_suspend is not
defined (only one Nvidia pci usb hcd defines it)
the usb_port_suspend/usb_port_resume will
do port suspend/resume(as well as msleep (10)) if there is a devivce
on the port, the ehci_bus_suspend/ehci_bus_resume will not send suspend/resume.
so, the msleep (10) is not needed.
So, this 10ms delay at hcd_bus_resume is only needed meets below conditions:
- device on the port
- The resume is sent by bus resume routine
- There is no delay after resume signal ends up
>
> Other HCDs will need the delay... but only if there are unsuspended
> enabled ports. The way to find out is to send a series of
> Get-Port-Status requests to the root hub. This has to be done after
> the spinlocked region that follows the existing msleep call.
>
> Alan Stern
>
>
--
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
