[U-Boot] [PATCH v5 4/4] usb: Change power-on / scanning timeout handling
Stefan Roese
sr at denx.de
Thu Apr 28 08:12:11 CEST 2016
On 28.04.2016 01:07, Marek Vasut wrote:
> On 04/02/2016 11:21 PM, Hans de Goede wrote:
>> Hi,
>
> Hi!
>
>> On 04/02/2016 12:22 AM, Marek Vasut wrote:
>>> On 03/15/2016 01:59 PM, Stefan Roese wrote:
>>>> This patch changes the USB port scanning procedure and timeout
>>>> handling in the following ways:
>>>>
>>>> a)
>>>> The power-on delay in usb_hub_power_on() is now reduced to a value of
>>>> max(100ms, "hub->desc.bPwrOn2PwrGood * 2"). The code does not wait
>>>> using mdelay, instead usb_hub_power_on() will wait before querying
>>>> the device in the scanning loop later. The total timeout for this
>>>> hub, which is 1 second + "hub->desc.bPwrOn2PwrGood * 2" is calculated
>>>> and will be used in the following per-port scanning loop as the timeout
>>>> to detect active USB devices on this hub.
>>>>
>>>> b)
>>>> Don't delay the minimum delay (for power to stabilize) in
>>>> usb_hub_power_on(). Instead skip querying these devices in the scannig
>>>> loop until the delay time is reached.
>>>>
>>>> c)
>>>> The ports are now scanned in a quasi parallel way. The current code did
>>>> wait for each (unconnected) port to reach its timeout and only then
>>>> continue with the next port. This patch now changes this to scan all
>>>> ports of all USB hubs quasi simultaneously. For this, all ports are
>>>> added
>>>> to a scanning list. This list is scanned until all ports are ready
>>>> by either a) reaching the connection timeout (calculated earlier), or
>>>> by b) detecting a USB device. This results in a faster USB scan time as
>>>> the recursive scanning of USB hubs connected to the hub that's currently
>>>> being scanned will start earlier.
>>>>
>>>> One small functional change to the original code is, that ports with
>>>> overcurrent detection will now get rescanned multiple times
>>>> (PORT_OVERCURRENT_MAX_SCAN_COUNT).
>>>>
>>>> Without this patch:
>>>> starting USB...
>>>> USB0: USB EHCI 1.00
>>>> scanning bus 0 for devices... 9 USB Device(s) found
>>>>
>>>> time: 20.163 seconds
>>>>
>>>> With this patch:
>>>> starting USB...
>>>> USB0: USB EHCI 1.00
>>>> scanning bus 0 for devices... 9 USB Device(s) found
>>>>
>>>> time: 1.822 seconds
>>>>
>>>> So ~18.3 seconds of USB scanning time reduction.
>>>>
>>>> Signed-off-by: Stefan Roese <sr at denx.de>
>>>> Acked-by: Hans de Goede <hdegoede at redhat.com>
>>>> Tested-by: Stephen Warren <swarren at nvidia.com>
>>>
>>> This breaks DWC2 on SoCkit, I can no longer detect any USB device.
>>> USB works without this patch though. Ideas?
>>
>> Have you tried simply adding a large sleep before the
>> initial uart, or doing an "usb reset" after the initial
>> scan ?
>
> Yeah, that doesn't help. But I also sent a few fixes for the DWC2
> controller, so let's see. I also finally got Stefan a working board,
> so he can start poking around :)
Okay, here my collection of tests with numerous USB keys on SoCFPGA
(SoCrates). All these tests were made with current mainline U-Boot
and the following patches applied:
http://patchwork.ozlabs.org/patch/614747/
http://patchwork.ozlabs.org/patch/615647/
http://patchwork.ozlabs.org/patch/615650/
http://patchwork.ozlabs.org/patch/615649/
http://patchwork.ozlabs.org/patch/615651/
a) With current mainline (USB scanning enhancement patch included)
and
b) USB scanning enhancement patch reverted (usb: Change power-on /
scanning timeout handling
I've used the following command to test the USB sticks:
dcache off;time usb start;usb tree
1. Kingston DataTraveler 2.0 (64GiB):
-------------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... Device NOT ready
Request Sense returned 00 00 00
2 USB Device(s) found
time: 2 minutes, 1.880 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
Kingston DataTraveler 2.0 50E549C688C4BE7189942766
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... Device NOT ready
Request Sense returned 00 00 00
2 USB Device(s) found
time: 2 minutes, 2.784 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
Kingston DataTraveler 2.0 50E549C688C4BE7189942766
2. "Paradise" (USBest Technology USB Mass Storage Device) 4GiB:
---------------------------------------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 0.936 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 98mA)
USBest Technology USB Mass Storage Device 09092207fbf0c4
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.571 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 98mA)
USBest Technology USB Mass Storage Device 09092207fbf0c4
3. Intenso Alu Line 16GiB:
--------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 1 USB Device(s) found
time: 1.390 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
U-Boot Root Hub
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 2.447 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
6989 Intenso Alu Line EE706F5E
4. Transcent USB 3.0 JF780 (JetFlash) 16GiB:
--------------------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.317 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
JetFlash Mass Storage Device 3281440601
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.398 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
JetFlash Mass Storage Device 3281440601
5. Transcend (JetFlash) 16GiB:
------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 1 USB Device(s) found
time: 1.390 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
U-Boot Root Hub
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.880 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 200mA)
JetFlash Mass Storage Device 55DECDA5
6. Kingston DataTraveler DTSE9 16GiB:
-------------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 0.580 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 300mA)
Kingston DataTraveler 2.0 C860008863CCBFC07A0668FC
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.485 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 300mA)
Kingston DataTraveler 2.0 C860008863CCBFC07A0668FC
7. microSD card in very "cheap" USB-microSD card reader:
--------------------------------------------------------
a)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 0.512 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 500mA)
b)
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
time: 1.397 seconds
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Mass Storage (480 Mb/s, 500mA)
In summary, I have only 2 USB sticks here, where I can see a
regression with the USB scanning patch. These are the following
USB sticks:
3. Intenso Alu Line 16GiB
5. Transcend (JetFlash) 16GiB
I've experimented with "usb_pgood_delay" a bit and both USB
keys start to work with a value of 700ms (600 does not work
always). So 1000 seems to be a safe value for "usb_pgood_delay"
on SoCFPGA right now.
My current feeling is that this problem is more related to the
DWC2 driver than the general USB scanning code that my patch
enhances. As such USB key detection regressions have not been
observed on other platforms so far. Even using the same problematic
USB sticks listed above. Reverting this USB scanning patch will
only paper over the main issue that is very likely hidden in
the DWC2 driver (or the SoCFPGA specific part of it). So I'm
definitely against revering this patch but instead using
"usb_pgood_delay=1000" on SoCFPGA for this release.
Thanks,
Stefan
More information about the U-Boot
mailing list