| Message ID | 20231130154229.22334-1-wahrenst@gmx.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: dts: bcm2711: Add generic xHCI | expand |
Hi Stefan, Stefan Wahren <wahrenst@gmx.net> (2023-11-30): > In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board > does not have a VL805 USB 3.0 host controller, which is connected via > PCIe. Instead, the BCM2711 on the Compute Module provides the built-in > xHCI. > > Changes in V2: > - adjust xHCI compatible as suggested by Justin & Florian > - keep xHCI disabled in order to let the bootloader decide which > USB block should be enabled, which result in a drop of patch 3 > > Stefan Wahren (2): > dt-bindings: usb: xhci: Add optional power-domains > ARM: dts: bcm2711: Add generic xHCI > > .../devicetree/bindings/usb/generic-xhci.yaml | 3 +++ > arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi | 5 +++++ > arch/arm/boot/dts/broadcom/bcm2711.dtsi | 14 ++++++++++++++ > 3 files changed, 22 insertions(+) Thanks, tests look much better this time! Tested-by: Cyril Brulebois <cyril@debamax.com> With CM4 Lite on CM4 IO Board, with a Samsung flash drive and a USB keyboard connected to onboard USB ports, I'm getting the following results (still with a Debian 12 arm64 userspace): 1. With unpatched kernel and unmodified config.txt: Both USB devices are working fine. 2. With unpatched kernel and otg_mode=1 in config.txt: Both USB devices disappear. lsmod reports dwc2 is no longer loaded, along with all USB and SCSI related modules. 3. With patched kernel and unmodified config.txt: Both USB devices are still working fine. lsmod confirms dwc2 is still used. 4. With patched kernel and otg_mode=1 in config.txt: Both USB devices are still working fine. lsmod reports dwc2 is going away, and other USB modules come up: usbhid, xhci_hcd, xhci_plat_hcd, along with others like hid, hid_generic, joydev. Reading from the Samsung flash drive gives a little boost, from 37.5 MB/s to 38.7 MB/s. Writing to it gives a little boost, from 16.5 MB/s to 17.4 MB/s. Not as spectacular as Florian's results but still not a regression! :) I tested that initially with a CM4 Lite Rev 1.0 (which was breaking case number 3 with the v1 of this patch series), then extended testing to CM4 8/32 Rev 1.0 and CM4 4/32 Rev 1.1, which confirmed those results. Adding a PCIe-to-USB expansion board to see if this has side effects on other USB things, that still works fine in cases 3 and 4 (so without or with otg_mode=1), having a Samsung flash drive on the PCIe-to-USB board and another one the onboard USB port. At this point, I only verified the block devices were reported by lsblk though (no actual transfer tests). Of course that relies on also applying Jim Quinlan's PCIe patch series v8 to make sure PCIe isn't an issue: https://lore.kernel.org/all/20231126201946.ffm3bhg5du2xgztv@mraw.org/ I've confirmed the presence of both Samsung flash drives with three different cards (adding CONFIG_USB_XHCI_PCI_RENESAS=m to the config shared in the v1 thread, and adding /lib/firmware/renesas_usb_fw.mem): - SupaHub PCE6U1C-R02, VER 006 - SupaHub PCE6U1C-R02, VER 006S - Waveshare PCIe TO USB 3.2 Gen1 (B) https://www.waveshare.com/wiki/PCIe_TO_USB_3.2_Gen1_(B) Finally, I've deployed the patched kernel (still this v2 plus Jim's v8) in a CM4-based product that uses both onboard USB ports and PCIe-to-USB ports, and all USB components still work fine (3 RF adapters, 1 modem). That's the case with an unmodified config.txt, but also when adding otg_mode=1: - xhci_pci and xhci_pci_renesas were already loaded; - xhci_plat_hcd appears in OTG mode, while dwc2 goes away. Cheers,