[PATCH 0/3] ARM: dts: bcm2711-rpi-cm4-io: Enable xHCI host

[Phil Elwell]

On Tue, 28 Nov 2023 at 06:44, Stefan Wahren <wahrenst at gmx.net> wrote:
>
>
> Am 27.11.23 um 22:49 schrieb Florian Fainelli:
> > On 11/27/23 11:22, Stefan Wahren wrote:
> >> Hi,
> >>
> >> Am 27.11.23 um 19:41 schrieb Florian Fainelli:
> >>> On 11/27/23 09:44, Justin Chen wrote:
> >>>>
> >>>>
> >>>> On 11/27/23 8:28 AM, Phil Elwell wrote:
> >>>>> On Mon, 27 Nov 2023 at 12:39, Stefan Wahren <wahrenst at gmx.net> wrote:
> >>>>>>
> >>>>>> Hi Phil,
> >>>>>>
> >>>>>>>>>> Hi Justin,
> >>>>>>>>>>
> >>>>>>>>>> [add Phil]
> >>>>>>>>>>
> >>>>>>>>>> Am 27.11.23 um 07:02 schrieb Justin Chen:
> >>>>>>>>>>> On 11/25/23 6:56 PM, Stefan Wahren wrote:
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>> Does this work? I maintain this built-in xHCI controller
> >>>>>>>>>>> internally. I
> >>>>>>>>>>> wasn't aware the Compute Module uses this block.
> >>>>>>>>>> i successful tested this with a CM4 (arm 32 bit,
> >>>>>>>>>> multi_v7_lpae_defconfig) with eMMC. Before this series the USB
> >>>>>>>>>> devices
> >>>>>>>>>> (mouse, keyboard) connected to the host interface didn't work.
> >>>>>>>>>> After
> >>>>>>>>>> comparing vendor DTS with mainline i noticed the missing xHCI
> >>>>>>>>>> block [1].
> >>>>>>>>>> Unfortunately i wasn't able to get further information from the
> >>>>>>>>>> public
> >>>>>>>>>> datasheets. I don't know if the VideoCore does some magic
> >>>>>>>>>> tricks on the
> >>>>>>>>>> xHCI or i missed some downstream xHCI changes.
> >>>>>>>>>>
> >>>>>>>>>>> This block is held in reset and needs a bit toggled to get
> >>>>>>>>>>> things
> >>>>>>>>>>> going. Florian, just to confirm, this is our
> >>>>>>>>>>> "brcm,xhci-brcm-v2" block
> >>>>>>>>>>> correct?
> >>>>>>>>>>>
> >>>>>>>>>>> Justin
> >>>>>>>>>> [1]  -
> >>>>>>>>>> https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2711-rpi-ds.dtsi#L119
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> What's the question here? Does the XHCI block present in the
> >>>>>>>>> raspberrypi/linux dtsi file really exist? Yes it does.
> >>>>>>>> since i don't have any documentation about the xHCI block, i
> >>>>>>>> assumed the
> >>>>>>>> compatible generic-xhci is correct. But Justin seems to suggest
> >>>>>>>> that the
> >>>>>>>> xHCI block needs some special treatment and we need a specific
> >>>>>>>> compatible.
> >>>>>>>>
> >>>>>>>> Did i missed some xHCI driver changes?
> >>>>>>>> Does the VC firmware something to the xHCI especially on CM4?
> >>>>>>> The firmware switches the on-board USB pins from DWC-OTG to XHCI if
> >>>>>>> otg_mode=1 is set in config.txt, or if booting over USB MSD.
> >>>>>> is this pinctrl/pinmux available from ARM via 0x7e200000 or a
> >>>>>> different
> >>>>>> IO address?
> >>>>>
> >>>>> It's in a different, undocumented block.
> >>>>>
> >>>>> Phil
> >>>>
> >>>> Well if it works, then maybe I am misunderstanding something here.
> >>>> Maybe its time for me to pick up a CM4 board.
> >>> There is one on my desk that you are welcome to use, or remote into if
> >>> you prefer.
> >>>
> >>> To answer your earlier question, yes this is the same block as the one
> >>> present in 72112 for which we use the "brcm,xhci-brcm-v2" compatible
> >>> string, it would be preferable to have it backed by that compatible
> >>> string in case we happen to support suspend/resume on the Pi 4B one
> >>> day, if nothing else.
> >>>
> >>> I did confirm that after applying Stefan's patches plus changing my
> >>> config.txt to have otg_mode=1, USB continues to be fully functional.
> >>> This is the case with using both "generic-xhci" or "brcm,xhci-brcm-v2"
> >>> so with the minor request to update the compatible to
> >>> "brcm,xhci-brcm-v2", this is:
> >>>
> >>> Tested-by: Florian Fainelli <florian.fainelli at broadcom.com>
> >>>
> >>> Stefan, I am getting a deadlock on boot if I leave your changes in and
> >>> uncomment dwc_otg=1 in config.txt, is there an alias or something that
> >>> the boot loader should be patching?
> >>
> >> sorry but i'm unable reproduce those deadlocks, neither in arm or arm64,
> >> with eMMC or without eMMC, xhci builtin or module. If i uncomment this
> >> in config.txt, USB host is just disabled.
> >
> > Here is my config.txt FWIW:
> >
> > # A bit too verbose
> > uart_2ndstage=1
> > enable_uart=1
> > arm_64bit=1
> > # Custom kernel images
> > kernel=kernel8-upstream.img
> > #kernel=kernel7l.img
> > #device_tree=bcm2711-rpi-4-b-UPSTREAM.dtb
> > device_tree=bcm2711-rpi-cm4-io-UPSTREAM.dtb
> > force_turbo=1
> > # DWC-OTG <=> XHCI
> > #otg_mode=1
> >
> >>
> >> I'm using the following firmware:
> >>
> >> raspberrypi-firmware soc:firmware: Attached to firmware from
> >> 2023-03-17T10:50:39
> >
> > OK, my CM4 is at 2022-07-25T15:10:17, updating to 2023-10-17T15:39:16
> > does not really show any difference.
> >
> >>
> >> Is this DTS difference a problem?
> >
> > It does not appear so, changing the node unit-name does not affect the
> > results.
> >
> >>
> >> upstream   -> xhci: usb at 7e9c0000
> >> downstream -> xhci: xhci at 7e9c0000
> >
> > Side question: does the VPU boot ROM or firmware take care of
> > configuring the USB PHY somehow? Should not we also have a Device Tree
> > node for it eventually?
>
> Sorry, as the person with the least knowledge about the hardware i
> cannot answer this question. But we should avoid those nop-PHY because
> they have source of regressions in the past.

The EEPROM firmware initialises the USB PHY.

Phil