USB2 only operation on IMX8QXP USB3 interface

[bhallen]

I have a custom set of hardware that I'm trying to get the USB2/3 port to act only as a USB2 port properly. Overall I can get it to work, but it doesn't always work well and the kernel has complaints.

To begin with, I terminated the USB3 per the hardware development guide. I tied the Rx and Tx pairs together and grounded them though a 10k resistor. It's a host-only port - ID is grounded through 10k and VBus tied to 3.3V.

In device tree, I removed the endpoint references the MEK has since there is no USB-C, just a plain type-A. The device tree has been pretty well customized for my board though. The USB3 section is simply this:

&usb3_phy {
  status = "okay";
};

&usbotg3 {
  status = "okay";
};

&usbotg3_cdns3 {
  dr_mode = "host";
  maximum-speed = "high-speed";
  /* usb-role-switch; */
  status = "okay";
};

The defconfig has only had a few drivers added to it from the default imx_v8_defconfig:
+CONFIG_TOUCHSCREEN_EDT_FT5X06=y
+CONFIG_RTC_DRV_PCF85063=y
+CONFIG_BH1750=y
+CONFIG_EXFAT_FS=y
+CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
+CONFIG_SND_SOC_TAS5720=y

Kernel Version:
Linux not-your-imx8x 5.10.72 #28 SMP PREEMPT Mon May 2 16:29:51 EDT 2022 aarch64 aarch64 aarch64 GNU/Linux

While a USB thumb drive is inserted into the port, everything is fine. I can mount & unmount filesystems, run the rootfs off of it, etc. When it's not inserted, I get the following dmesg repeating every few seconds:

[ 736.663440] cdns3-imx 5b110000.usb: wait lpm_clk_req timeout
[ 736.763464] cdns3-imx 5b110000.usb: wait phy_refclk_req timeout

Then at some point I'll get a kernel error from "cdns3_runtime_suspend":

[ 93.511676] irq 151: nobody cared (try booting with the "irqpoll" option)
[ 93.518480] CPU: 0 PID: 185 Comm: kworker/0:2 Not tainted 5.10.72-lts-5.10.y+gcf2d66861ffb #1
[ 93.527013] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 93.532169] Workqueue: pm pm_runtime_work
[ 93.536187] Call trace:
[ 93.538643] dump_backtrace+0x0/0x1a0
[ 93.542307] show_stack+0x18/0x70
[ 93.545627] dump_stack+0xd0/0x12c
[ 93.549030] __report_bad_irq+0x4c/0xdc
[ 93.552872] note_interrupt+0x2d8/0x39c
[ 93.556710] handle_irq_event+0xd8/0x150
[ 93.560637] handle_fasteoi_irq+0xa4/0x1f4
[ 93.564736] __handle_domain_irq+0x7c/0xe0
[ 93.568838] gic_handle_irq+0xc0/0x140
[ 93.572588] el1_irq+0xcc/0x180
[ 93.575735] efi_header_end+0xa4/0x290
[ 93.579489] irq_exit+0xdc/0xfc
[ 93.582632] __handle_domain_irq+0x80/0xe0
[ 93.586733] gic_handle_irq+0xc0/0x140
[ 93.590485] el1_irq+0xcc/0x180
[ 93.593632] cdns3_runtime_suspend+0x40/0x84
[ 93.597906] pm_generic_runtime_suspend+0x30/0x50
[ 93.602614] __rpm_callback+0x90/0x160
[ 93.606366] rpm_callback+0x24/0x84
[ 93.609860] rpm_suspend+0x104/0x55c
[ 93.613440] rpm_idle+0xac/0x160
[ 93.616672] pm_runtime_work+0xa4/0xcc
[ 93.620426] process_one_work+0x1cc/0x350
[ 93.624437] worker_thread+0x138/0x46c
[ 93.628190] kthread+0x154/0x160
[ 93.631421] ret_from_fork+0x10/0x30
[ 93.634998] handlers:
[ 93.637278] [<000000002d28a50e>] cdns3_wakeup_irq
[ 93.641983] [<000000003360e13e>] cdns3_drd_irq threaded [<00000000b12a61d5>]
cdns3_drd_thread_irq
[ 93.650873] [<00000000bd662b79>] usb_hcd_irq
[ 93.655144] Disabling IRQ #151
[ 95.045750] cdns3-imx 5b110000.usb: wait lpm_clk_req timeout
[ 95.151456] cdns3-imx 5b110000.usb: wait phy_refclk_req timeout

After I get the kernel error, the port will still work, but very slowly which doesn't give me a lot of confidence.

It's clearly related to the power management when the kernel wants to put the port in low power mode when nothing is attached. For some reason the clock change times out. I tried briefly to disable the PM in the cadence driver, but that went nowhere fast.

Any ideas? Should I have left the USB3 lines unterminated?

[bhallen · Accepted solution]

To answer my own question.. Having the USB3 signals terminated while using the USB2 part of the port is the cause of the errors.

I had the processor removed and cut the traces that shorted the USB3 signals together before going to a pull down resistor. After the operation, it behaves as it should.