On 03.05.2016 22:51, Marek Vasut wrote:
Increase the query delay, otherwise some sticks are not detected. The problem shows up on the USB bus analyzer such that the stick takes longer time to switch from FS mode to HS mode than the code allows.
Signed-off-by: Marek Vasut marex@denx.de Cc: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Hans de Goede hdegoede@redhat.com Cc: Stefan Roese sr@denx.de Cc: Stephen Warren swarren@nvidia.com
common/usb_hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c index 0f39c9f..6cd274a 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -145,7 +145,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub) * Do a minimum delay of the larger value of 100ms or pgood_delay * so that the power can stablize before the devices are queried */
- hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
hub->query_delay = get_timer(0) + max(1000, (int)pgood_delay);
/*
- Record the power-on timeout here. The max. delay (timeout)
We have touched this part of the delay a number of times in my USB scanning patch series. I've integrated all very valuable suggestions from Stephen and Hans and I'm pretty sure that the current implementation is aligned with the USB spec. And tested successfully one multiple platforms without regression. Stephen did some tests on Tegra and Hans on sunxi. I tested mainly on x86. But I now also tested on Armada XP (see below).
As mentioned before, the current version causes no problems with all my USB sticks on the congatec x86 board. Even the 2 ones that are problematic when connected to the SoCFPGA. They are detected without any issues on this board. Thats why I assume, that the real problem here is the DWC driver and not the generic USB handling code. My feeling is that increasing this initial delay (before the scanning starts) just papers over the real problem most likely hidden somewhere in the DWC driver. This is just a feeling though which I can't prove somehow other than testing the common USB code on different platforms. And I really have no deeper knowledge of the DWC driver to manifest this feeling or even fix this potential problem there.
I've already mentioned this in another mail. My suggestion for SoCFPGA boards that need to use these problematic USB keys is to use the already available solution to set "usb_pgood_delay" to 1000. This effectively does the same as this patch. Without implying this general 1 second delay per hub (!!!) to all other platforms that use USB in U-Boot.
To test my suspicions about this being a DWC (SoCFPGA?) only problem, I've also tested all my current USB sticks including the 2 problematic ones (on SoCrates) on another ARM platform (additionally to all my test on x86). I've used the Marvell Armada XP development board (db-mv784mp-gp) for this. And all USB sticks are detected without any problems on this platform.
As a result of all this, I would like to have this patch not applied. As it negatively touches the common USB code to fix (paper over?) a problem only seen on one platform (AFAIK). And we already have the solution of this "usb_pgood_delay" that can be used on SoCFPGA. To manifest this, here again the numbers for the USB scanning time on x86, without and with this patch:
Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found
time: 1.940 seconds
With this patch: => time usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found
time: 5.421 seconds
Thanks, Stefan