imx8mm/imx8mn hang on usb stop / ehci_shutdown
Greetings,
I'm seeing a hang on imx8mm-venice and imx8mn-venice boards which have a USB host controller in host mode when ehci_shutdown() is called (which is called for 'usb stop' as well as when booting a kernel once 'usb start' has been issued).
This appears to be caused by the ehci_shutdown() function, specifically the write to the or_portsc register to set EHCI_PS_SUSP: for (i = 0; i < max_ports; i++) { reg = ehci_readl(&ctrl->hcor->or_portsc[i]); reg |= EHCI_PS_SUSP; ehci_writel(&ctrl->hcor->or_portsc[i], reg); }
Does anyone else out there with an imx8mm/imx8mn board with usbotg1 or usbotg2 configured with dr_mode="host" see this as well?
I'm not clear where the equivalent code would be in the Linux kernel to compare with. I do know that commenting out the ehcI_write above keeps ehci_shutdown from hanging but does cause the handshake to fail on the next cmd that disables CMD_RUN and thus prints "EHCI failed to shut down host controller.".
Any ideas?
Best Regards,
Tim
On Wed, Mar 15, 2023 at 3:01 PM Tim Harvey tharvey@gateworks.com wrote:
Greetings,
I'm seeing a hang on imx8mm-venice and imx8mn-venice boards which have a USB host controller in host mode when ehci_shutdown() is called (which is called for 'usb stop' as well as when booting a kernel once 'usb start' has been issued).
This appears to be caused by the ehci_shutdown() function, specifically the write to the or_portsc register to set EHCI_PS_SUSP: for (i = 0; i < max_ports; i++) { reg = ehci_readl(&ctrl->hcor->or_portsc[i]); reg |= EHCI_PS_SUSP; ehci_writel(&ctrl->hcor->or_portsc[i], reg); }
Does anyone else out there with an imx8mm/imx8mn board with usbotg1 or usbotg2 configured with dr_mode="host" see this as well?
I'm not clear where the equivalent code would be in the Linux kernel to compare with. I do know that commenting out the ehcI_write above keeps ehci_shutdown from hanging but does cause the handshake to fail on the next cmd that disables CMD_RUN and thus prints "EHCI failed to shut down host controller.".
Any ideas?
Best Regards,
Tim
I haven't heard any response here so I did some more digging. This hang should be affecting all imx8mm/imx8mn devices that have USB host controllers configured for host mode (dr_mode = "host") and would appear for anyone that ever does a 'usb stop' (or does a 'usb start' followed by a kernel boot for example of loading kernel from USB) in U-Boot.
The issue is caused by the pgc_otg{1,2} and/or pgc_hsiomix power domains getting disabled for the 'usb_hub' device (which is present for the USB host even if you have no hub) prior to ehci_shutdown being called.
The following patch resolves this but I'm thinking there should be a better way to control this from ehci-mx6.c?
diff --git a/common/usb_hub.c b/common/usb_hub.c index 85c0822d8b7b..03237deaa0be 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -948,7 +948,7 @@ U_BOOT_DRIVER(usb_generic_hub) = { .name = "usb_hub", .id = UCLASS_USB_HUB, .of_match = usb_hub_ids, - .flags = DM_FLAG_ALLOC_PRIV_DMA, + .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_LEAVE_PD_ON, };
Best Regards,
Tim
Hi Tim,
On Thu, Apr 27, 2023 at 2:14 PM Tim Harvey tharvey@gateworks.com wrote:
I haven't heard any response here so I did some more digging. This hang should be affecting all imx8mm/imx8mn devices that have USB host controllers configured for host mode (dr_mode = "host") and would appear for anyone that ever does a 'usb stop' (or does a 'usb start' followed by a kernel boot for example of loading kernel from USB) in U-Boot.
Yes, I recall seeing this issue some time ago but never got a chance to debug it.
Just tested mainline U-Boot on an imx8mm-evk and there is still a different issue:
"ums 0 mmc 1" works fine for the first time and it mounts the content of the SD card correctly on the PC.
After hitting CTRL+C: CTRL+C - Operation aborted clk usb_bus already disabled
And after running "ums 0 mmc 1" again, it does not mount the SD card anymore.
On Thu, Apr 27, 2023 at 12:14 PM Tim Harvey tharvey@gateworks.com wrote:
On Wed, Mar 15, 2023 at 3:01 PM Tim Harvey tharvey@gateworks.com wrote:
Greetings,
I'm seeing a hang on imx8mm-venice and imx8mn-venice boards which have a USB host controller in host mode when ehci_shutdown() is called (which is called for 'usb stop' as well as when booting a kernel once 'usb start' has been issued).
This appears to be caused by the ehci_shutdown() function, specifically the write to the or_portsc register to set EHCI_PS_SUSP: for (i = 0; i < max_ports; i++) { reg = ehci_readl(&ctrl->hcor->or_portsc[i]); reg |= EHCI_PS_SUSP; ehci_writel(&ctrl->hcor->or_portsc[i], reg); }
Does anyone else out there with an imx8mm/imx8mn board with usbotg1 or usbotg2 configured with dr_mode="host" see this as well?
I'm not clear where the equivalent code would be in the Linux kernel to compare with. I do know that commenting out the ehcI_write above keeps ehci_shutdown from hanging but does cause the handshake to fail on the next cmd that disables CMD_RUN and thus prints "EHCI failed to shut down host controller.".
Any ideas?
Best Regards,
Tim
I haven't heard any response here so I did some more digging. This hang should be affecting all imx8mm/imx8mn devices that have USB host controllers configured for host mode (dr_mode = "host") and would appear for anyone that ever does a 'usb stop' (or does a 'usb start' followed by a kernel boot for example of loading kernel from USB) in U-Boot.
The issue is caused by the pgc_otg{1,2} and/or pgc_hsiomix power domains getting disabled for the 'usb_hub' device (which is present for the USB host even if you have no hub) prior to ehci_shutdown being called.
The following patch resolves this but I'm thinking there should be a better way to control this from ehci-mx6.c?
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
adam
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ar...
diff --git a/common/usb_hub.c b/common/usb_hub.c index 85c0822d8b7b..03237deaa0be 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -948,7 +948,7 @@ U_BOOT_DRIVER(usb_generic_hub) = { .name = "usb_hub", .id = UCLASS_USB_HUB, .of_match = usb_hub_ids,
.flags = DM_FLAG_ALLOC_PRIV_DMA,
.flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_LEAVE_PD_ON,};
Best Regards,
Tim
Hi Adam,
On Thu, Apr 27, 2023 at 2:42 PM Adam Ford aford173@gmail.com wrote:
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it does fix the "ums 0 mmc 1" issue I just described.
I will submit the dtsi sync patch. Thanks!
On Thu, Apr 27, 2023 at 10:49 AM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, Apr 27, 2023 at 2:42 PM Adam Ford aford173@gmail.com wrote:
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it does fix the "ums 0 mmc 1" issue I just described.
I will submit the dtsi sync patch. Thanks!
Fabio,
The original issue I was trying to solve should not be visible on imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which case you should see a hang with a simple 'usb start && usb stop'.
Best Regards,
Tim
On Thu, Apr 27, 2023 at 12:52 PM Tim Harvey tharvey@gateworks.com wrote:
On Thu, Apr 27, 2023 at 10:49 AM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, Apr 27, 2023 at 2:42 PM Adam Ford aford173@gmail.com wrote:
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it does fix the "ums 0 mmc 1" issue I just described.
I will submit the dtsi sync patch. Thanks!
Fabio,
The original issue I was trying to solve should not be visible on imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which case you should see a hang with a simple 'usb start && usb stop'.
If you leave it without the "host" but connect a device to the port with a host adapter, do you get the same behavior?
adam
Best Regards,
Tim
On Thu, Apr 27, 2023 at 10:54 AM Adam Ford aford173@gmail.com wrote:
On Thu, Apr 27, 2023 at 12:52 PM Tim Harvey tharvey@gateworks.com wrote:
On Thu, Apr 27, 2023 at 10:49 AM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, Apr 27, 2023 at 2:42 PM Adam Ford aford173@gmail.com wrote:
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it does fix the "ums 0 mmc 1" issue I just described.
I will submit the dtsi sync patch. Thanks!
Fabio,
The original issue I was trying to solve should not be visible on imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which case you should see a hang with a simple 'usb start && usb stop'.
If you leave it without the "host" but connect a device to the port with a host adapter, do you get the same behavior?
Adam,
Yes, simply adding a USB OTG (or USB-C) to host cable (even without a device attached) will cause the hang.
The issue here is that ehci-mx6.c:ehci_usb_remove calls ehci_deregister which calls ehci_shutdown which accesses the EHCI registers to suspend the ports (after the imx8m power domains are disabled) which causes the hang. This is not called if the controller is not in host mode.
Tim
Hi Tim,
On Thu, Apr 27, 2023 at 2:52 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
The original issue I was trying to solve should not be visible on imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which case you should see a hang with a simple 'usb start && usb stop'.
Just did the following change as you suggested:
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi index 7d6317d95b13..0be3ab66ed5f 100644 --- a/arch/arm/dts/imx8mm-evk.dtsi +++ b/arch/arm/dts/imx8mm-evk.dtsi @@ -400,7 +400,7 @@ };
&usbotg1 { - dr_mode = "otg"; + dr_mode = "host"; hnp-disable; srp-disable; adp-disable; diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index ab9ad41b4548..70c7a21f2d9f 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -119,3 +119,4 @@ CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x40400000 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y +CONFIG_CMD_USB=y
Tested against my series that syncs imx8mm with Linux 6.3:
u-boot=> usb start && usb stop starting USB... Bus usb@32e40000: USB EHCI 1.00 scanning bus usb@32e40000 for devices... 1 USB Device(s) found stopping USB.. u-boot=>
No hang is observed.
On Thu, Apr 27, 2023 at 11:16 AM Fabio Estevam festevam@gmail.com wrote:
Hi Tim,
On Thu, Apr 27, 2023 at 2:52 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
The original issue I was trying to solve should not be visible on imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which case you should see a hang with a simple 'usb start && usb stop'.
Just did the following change as you suggested:
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi index 7d6317d95b13..0be3ab66ed5f 100644 --- a/arch/arm/dts/imx8mm-evk.dtsi +++ b/arch/arm/dts/imx8mm-evk.dtsi @@ -400,7 +400,7 @@ };
&usbotg1 {
dr_mode = "otg";
dr_mode = "host"; hnp-disable; srp-disable; adp-disable;diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index ab9ad41b4548..70c7a21f2d9f 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -119,3 +119,4 @@ CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x40400000 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y +CONFIG_CMD_USB=y
Tested against my series that syncs imx8mm with Linux 6.3:
u-boot=> usb start && usb stop starting USB... Bus usb@32e40000: USB EHCI 1.00 scanning bus usb@32e40000 for devices... 1 USB Device(s) found stopping USB.. u-boot=>
No hang is observed.
Fabio,
Do you have another board to test with that uses both imx8mm usb host controllers? With your imx8mm dtsi sync added a simple 'usb start' hangs on my imx8mm-gw71xx board when the second controller is enabled: starting USB... Bus usb@32e40000: USB EHCI 1.00 Bus usb@32e50000:
I don't believe the imx8mm-evk even has proper USB support in general (which is probably why CMD_USB is not enabled). Only one port is enabled in the dt and If I connect a USB-C to host cable with device in it to that port a 'usb tree' does not even show the device enumerated.
Tim
Hi Tim,
On Thu, Apr 27, 2023 at 3:46 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
Do you have another board to test with that uses both imx8mm usb host controllers? With your imx8mm dtsi sync added a simple 'usb start' hangs on my imx8mm-gw71xx board when the second controller is enabled: starting USB... Bus usb@32e40000: USB EHCI 1.00 Bus usb@32e50000:
No other imx8mm-based board here at the moment, sorry.
Without the imx8mm.dtsi sync patch, I was able to reproduce the hang after running "usb start && usb stop".
After the imx8mm.dtsi sync patch, I do not see the hang.
I don't believe the imx8mm-evk even has proper USB support in general (which is probably why CMD_USB is not enabled). Only one port is enabled in the dt and If I connect a USB-C to host cable with device in it to that port a 'usb tree' does not even show the device enumerated.
Yes, in U-Boot there is no ptn5110 driver, so the imx8mm-evk is not complete.
On Thu, Apr 27, 2023 at 11:52 AM Fabio Estevam festevam@gmail.com wrote:
Hi Tim,
On Thu, Apr 27, 2023 at 3:46 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
Do you have another board to test with that uses both imx8mm usb host controllers? With your imx8mm dtsi sync added a simple 'usb start' hangs on my imx8mm-gw71xx board when the second controller is enabled: starting USB... Bus usb@32e40000: USB EHCI 1.00 Bus usb@32e50000:
No other imx8mm-based board here at the moment, sorry.
Without the imx8mm.dtsi sync patch, I was able to reproduce the hang after running "usb start && usb stop".
After the imx8mm.dtsi sync patch, I do not see the hang.
it's possible the dts sync is indeed needed to resolve the issue I'm seeing but something else is needed along with it for usbotg2.
I don't believe the imx8mm-evk even has proper USB support in general (which is probably why CMD_USB is not enabled). Only one port is enabled in the dt and If I connect a USB-C to host cable with device in it to that port a 'usb tree' does not even show the device enumerated.
Yes, in U-Boot there is no ptn5110 driver, so the imx8mm-evk is not complete.
just enable usbotg2 controller in dt for imx8mm-evk and you'll see the hang:
+&usbotg2 { + status = "okay"; +}; +
u-boot=> usb start starting USB... Bus usb@32e40000: Bus usb@32e50000:
Tim
On Thu, Apr 27, 2023 at 11:58 AM Tim Harvey tharvey@gateworks.com wrote:
On Thu, Apr 27, 2023 at 11:52 AM Fabio Estevam festevam@gmail.com wrote:
Hi Tim,
On Thu, Apr 27, 2023 at 3:46 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
Do you have another board to test with that uses both imx8mm usb host controllers? With your imx8mm dtsi sync added a simple 'usb start' hangs on my imx8mm-gw71xx board when the second controller is enabled: starting USB... Bus usb@32e40000: USB EHCI 1.00 Bus usb@32e50000:
No other imx8mm-based board here at the moment, sorry.
Without the imx8mm.dtsi sync patch, I was able to reproduce the hang after running "usb start && usb stop".
After the imx8mm.dtsi sync patch, I do not see the hang.
it's possible the dts sync is indeed needed to resolve the issue I'm seeing but something else is needed along with it for usbotg2.
I don't believe the imx8mm-evk even has proper USB support in general (which is probably why CMD_USB is not enabled). Only one port is enabled in the dt and If I connect a USB-C to host cable with device in it to that port a 'usb tree' does not even show the device enumerated.
Yes, in U-Boot there is no ptn5110 driver, so the imx8mm-evk is not complete.
just enable usbotg2 controller in dt for imx8mm-evk and you'll see the hang:
+&usbotg2 {
status = "okay";+};
u-boot=> usb start starting USB... Bus usb@32e40000: Bus usb@32e50000:
Tim
Fabio,
The patch series from Eugen Hristev which implements reference counting for regulators [1] resolves my issue here so I consider this thread closed.
Let's move the discussion regarding your dt sync to those threads.
Best Regards,
Tim [1] https://patchwork.ozlabs.org/project/uboot/list/?series=351536
On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, Apr 27, 2023 at 2:42 PM Adam Ford aford173@gmail.com wrote:
There was some re-organization of the power domains in Linux in the device tree [1]. Do you know if those propagated to U-Boot?
Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it does fix the "ums 0 mmc 1" issue I just described.
I will submit the dtsi sync patch. Thanks!
Any chance you can update the imx8mn.dtsi as well when you do the patch? Nano has the same USB controller, it's likely to have the same issue.
adam
On Thu, Apr 27, 2023 at 2:55 PM Adam Ford aford173@gmail.com wrote:
Any chance you can update the imx8mn.dtsi as well when you do the patch? Nano has the same USB controller, it's likely to have the same issue.
Yes, I plan to update imx8mm, imx8mn and imx8mp.
Will send the series shortly.
Thanks
participants (3)
-
Adam Ford -
Fabio Estevam -
Tim Harvey