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

[Florian Fainelli <florian.fainelli@broadcom.com>]

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

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?
-- 
Florian


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]