Use the uthread framework to initialize and scan USB buses in parallel
for better performance. The console output is slightly modified with a
final per-bus report of the number of devices found, common to UTHREAD
and !UTHREAD. The USB tests are updated accordingly.
Tested on two platforms:
1. arm64 QEMU on a somewhat contrived example (4 USB buses, each with
one audio device, one keyboard, one mouse and one tablet)
$ make qemu_arm64_defconfig
$ make -j$(nproc) CROSS_COMPILE="ccache aarch64-linux-gnu-"
$ qemu-system-aarch64 -M virt -nographic -cpu max -bios u-boot.bin \
$(for i in {1..4}; do echo -device qemu-xhci,id=xhci$i \
-device\ usb-{audio,kbd,mouse,tablet},bus=xhci$i.0; \
done)
2. i.MX93 EVK (imx93_11x11_evk_defconfig) with two USB hubs, each with
one webcam and one ethernet adapter, resulting in the following device
tree:
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| GenesysLogic USB2.1 Hub
|
+-3 Vendor specific (480 Mb/s, 350mA)
| Realtek USB 10/100/1000 LAN 001000001
|
+-4 (480 Mb/s, 500mA)
HD Pro Webcam C920 8F7CD51F
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| USB 2.0 Hub
|
+-3 Vendor specific (480 Mb/s, 200mA)
| Realtek USB 10/100/1000 LAN 000001
|
+-4 (480 Mb/s, 500mA)
Generic OnLan-CS30 201801010008
Note that i.MX was tested on top of the downstream repository [1] since
USB doesn't work in the upstream master branch.
[1] https://github.com/nxp-imx/uboot-imx/tree/lf-6.6.52-2.2.0
commit 6c4545203d12 ("LF-13928 update key for capsule")
The time spent in usb_init() ("usb start" command) is reported on
the console. Here are the results:
| CONFIG_UTHREAD=n | CONFIG_UTHREAD=y
--------+------------------+-----------------
QEMU | 5628 ms | 2212 ms
i.MX93 | 4591 ms | 2441 ms
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
To prepare for the introduction of threads in the USB initialization sequence, move code out of usb_init() into a new helper function: usb_init_bus() and count the number of USB controllers initialized successfully by using the DM device_active() function. Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Prepare v2024.07-rc5
The message 'No working controllers found' provides no clue that this refers to USB controllers. Provide a message that refers to USB. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from this driver directory and when needed add missing include files directly. Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Signed-off-by: Tom Rini <trini@konsulko.com>
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter again so does not see any devices. Fix this by telling bootstd about the state of USB. Signed-off-by: Simon Glass <sjg@chromium.org>
EHCI is usually used with companion controller (like OHCI) as companion controller. This information on the companion is missing currently in companion drivers. So, if the usb-uclass isn't aware, it may scan busses in any order: OHCI first, then EHCI. This is seen on STM32MP1 where DT probing makes the probe order to occur by increasing address (OHCI address < EHCI address). When a low speed or full-speed device is plugged in, it's not detected as EHCI should first detect it, and give ownership (handover) to OHCI. Current situation on STM32MP1 (with a low speed device plugged-in) STM32MP> usb start starting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800c000 for devices... 1 USB Device(s) found scanning bus usb@5800d000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found The "companion" property in the device tree allow to retrieve companion controller information, from the EHCI node. This allow marking the companion driver as such. With this patch (same low speed device plugged in): STM32MP> usb start starting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800d000 for devices... 1 USB Device(s) found scanning bus usb@5800c000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found STM32MP> usb tree USB device tree: 1 Hub (12 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (1.5 Mb/s, 100mA) HP HP USB 1000dpi Laser Mouse 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller This also optimize bus scan when a High speed device is plugged in, as the usb-uclass skips OHCI in this case: STM32MP> usb reset resetting USB... Bus usb@5800c000: USB OHCI 1.0 Bus usb@5800d000: USB EHCI 1.00 scanning bus usb@5800d000 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found STM32MP> usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) SanDisk Cruzer Blade 03003432021922011407 Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de>
When USB finds no devices it currently returns -EPERM which bootstd does not understand. This causes other bootdevs of the same priority to be skipped. Fix this by returning the correct error code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>