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

[Stefan Wahren <wahrenst@gmx.net>]

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@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@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.

I'm using the following firmware:

raspberrypi-firmware soc:firmware: Attached to firmware from
2023-03-17T10:50:39

Is this DTS difference a problem?

upstream   -> xhci: usb@7e9c0000
downstream -> xhci: xhci@7e9c0000