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

[Stefan Wahren]

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.