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.
> 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.
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
