On 10.03.2016 20:12, Hans de Goede wrote:
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
In a system with a complex USB infrastrcture (many USB hubs), the
power-on delay of mininimum 1 second for each USB hub results in a quite
big USB scanning time. Many USB devices can deal with much lower
power-on delays. In my test system, even 10ms seems to be enough
for the USB device to get detected correctly. This patch now
reduces the minimum 1 second delay to a minumum of 100ms instead.
This results in a big USB scan time reduction:
Here the numbers for my current board:
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 10.822 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 6.319 seconds
So ~4.5 seconds of USB scanning time reduction.
I'm not really sure if this patch can be accepted in general as is.
In patch 0d437bca [usb: hub: fix power good delay timing] by Stephen
Warren, this delay was changes according to "Connect Timing ECN.pdf"
to a total of 1 second plus the hub port's power good time. Now its
changes back to 100ms which is a violation of this spec. But still,
for most USB devices this 100ms is more than enough. So its a valid
use-case to lower this time in special (perhaps static) USB
environments.
Actually that 1 second + poweron delay is why we had the 1 sec
delay in usb_hub_configure(), that is where we wait for a device
to show up. Note that we can already save a lot of time, by
first powering up all ports and then doing the 1 sec wait
and then checking all ports without needing to delay any further.
Or even better:
1) turn on all ports
2) do power-on-delay (either 2ms * bPwrOn2PwrGood from descriptor, or
100ms which ever one is LARGER)
3) set a timeout val 1 sec from now, loop over all ports and quit
the loop when either all ports are connected (we already skip the
per port delay in this connected case now), or when the 1 sec
expires. There is no reason for the 1 sec per port delay,
one sec + bPwrOn2PwrGood delay is enough for all ports
Right. There's definitely room for improvement and optimization
here.
###
Note that even better would be to in 3 first calls some sort of
probe_prepare function, which if the child is a hub itself, does
the poweron, and records the timeout for its loop and runs its
loop once (to probe_prepare its children if they come up immediately).
And then only once the loop over all ports ends, call the real
probe which will then do usb_hub_configure() for its (hub)
children using the timeout recorded during the probe_prepare,
and will thus likely be able to skip a large part of that
1 sec waiting since that was already waited in the parent
hub's usb_hub_configure() call.
Note this would speed up scanning deep trees of hubs, if
we have multiple usb controllers, it would also be really
good to probe them in parallel as described here:
http://lists.denx.de/pipermail/u-boot/2016-February/245243.html
(yes I'm repeating myself :)
Thanks for your comments Hans. Lets see, what I can come up with in
next patchset version.
Thanks,
Stefan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
