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