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