On 18 July, 2008, Arjan van de Ven wrote:
> From: Arjan van de Ven <[email protected]>
> 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.
Alan Stern
On 19/07/08 16:25, Alan Stern wrote:
> On 18 July, 2008, Arjan van de Ven wrote:
>
>> From: Arjan van de Ven <[email protected]>
>> 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
On Sat, 19 Jul 2008 11:25:29 -0400 (EDT)
Alan Stern <[email protected]> wrote:
> On 18 July, 2008, Arjan van de Ven wrote:
>
> > From: Arjan van de Ven <[email protected]>
> > 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)
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sat, 19 Jul 2008, Arjan van de Ven wrote:
> On Sat, 19 Jul 2008 11:25:29 -0400 (EDT)
> Alan Stern <[email protected]> wrote:
>
> > On 18 July, 2008, Arjan van de Ven wrote:
> >
> > > From: Arjan van de Ven <[email protected]>
> > > 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
On Sat, 19 Jul 2008, Simon Arlott wrote:
> 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?
In fact it will, to a large extent. The new code isn't present in
2.6.26 but it ought to be in 2.6.27-rc1.
However Arjan wasn't talking about debounce delays; he was talking
about port-power-on delays. A nice improvement would be to combine the
two types of delay into one. I'll look into it...
Alan Stern