Re: [PATCH V2 0/2] ARM: dts: bcm2711: Add generic xHCI

[Cyril Brulebois <kibi@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3828 bytes --]

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,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]