Messages in this thread | | | Date | Sat, 19 Jul 2008 16:27:10 -0400 (EDT) | From | Alan Stern <> | Subject | Re: Re [patch 2/3] fastboot: turn the USB hostcontroller initcalls into async initcalls |
| |
On Sat, 19 Jul 2008, Arjan van de Ven wrote:
> On Sat, 19 Jul 2008 11:25:29 -0400 (EDT) > Alan Stern <stern@rowland.harvard.edu> wrote: > > > On 18 July, 2008, Arjan van de Ven wrote: > > > > > From: Arjan van de Ven <arjan@linux.intel.com> > > > Subject: [PATCH] fastboot: turn the USB hostcontroller initcalls > > > into async initcalls > > > > > > the USB host controller init calls take a long time, mostly due to a > > > "minimally 100 msec" delay *per port* during initialization. > > > These are prime candidates for going in parallel to everything else. > > > > > > The USB device ordering is not affected by this due to the > > > serialized-within-eachother property of async initcalls. > > > > > > Where is this "minimally 100 msec" per-port delay you refer to? > > Offhand I can't recall any such delays in the init routines. > > > > it's here (in drivers/usb/core/hub.c::hub_power_on): > > "non-switchable hub\n"); > for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) > set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER); > > /* Wait at least 100 msec for power to become stable */ > msleep(max(pgood_delay, (unsigned) 100)); > } > > at least my eeepc901 hits that like 6 or 7 times > (because if I shorten the 100 the boot goes a ton faster.. but that's > obviously just a bad hack)
That isn't a *per-port* delay. It's a single delay used concurrently for all the ports in the root hub; the msleep call occurs outside the "for" loop.
Maybe you meant 100 ms *per controller*. I agree, it's best for these delays to occur in parallel. Now if only we could do the same with suspend and resume...
Alan Stern
| |