On Tue, 28 Nov 2023 at 06:44, Stefan Wahren <wahrenst@xxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxx> > >>> > >>> 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@7e9c0000 > >> downstream -> xhci: xhci@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
