Messages in this thread | | | Date | Sat, 19 Jul 2008 16:32:20 +0100 | From | Simon Arlott <> | Subject | Re: Re [patch 2/3] fastboot: turn the USB hostcontroller initcalls into async initcalls |
| |
On 19/07/08 16:25, Alan Stern 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. > > Is there some reason this patch wasn't posted to the linux-usb mailing > list as well as to LKML? > > Where is this "minimally 100 msec" per-port delay you refer to? > Offhand I can't recall any such delays in the init routines. >
usb/core/hub.c:
/* USB 2.0 spec, 7.1.7.3 / fig 7-29: * * Between connect detection and reset signaling there must be a delay * of 100ms at least for debounce and power-settling. The corresponding * timer shall restart whenever the downstream port detects a disconnect. * * Apparently there are some bluetooth and irda-dongles and a number of * low-speed devices for which this debounce period may last over a second. * Not covered by the spec - but easy to deal with. * * This implementation uses a 1500ms total debounce timeout; if the * connection isn't stable by then it returns -ETIMEDOUT. It checks * every 25ms for transient disconnects. When the port status has been * unchanged for 100ms it returns the port status. */
Could it do that for all ports on the hub in parallel instead?
-- Simon Arlott
| |