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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux