usb: dwc3: Disable susphy during initialization

The xhci_plat.h should not need to include the entire xhci.h header. This can cause redefinition in dwc3 if it selectively includes some xHCI definitions. This is a prerequisite change for a fix to disable suspend during initialization for dwc3.

Cc [email protected]

Signed-off-by Thinh Nguyen <[email protected]>

---
 drivers/usb/host/xhci-plat.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/usb/host/xhci-plat.h +3 -1

index 2d15386f2c50..6475130eac4b 100644
@@ -8,7 +8,9 @@
 #ifndef _XHCI_PLAT_H
 #define _XHCI_PLAT_H
 
-#include "xhci.h"	/* for hcd_to_xhci() */
+struct device;
+struct platform_device;
+struct usb_hcd;
 
 struct xhci_plat_priv {
 	const char *firmware_name;

Signature · 1 line

2.28.0

Quoted 24 lines · Thinh Nguyen

The xhci_plat.h should not need to include the entire xhci.h header. This can cause redefinition in dwc3 if it selectively includes some xHCI definitions. This is a prerequisite change for a fix to disable suspend during initialization for dwc3.

Cc [email protected]

Signed-off-by Thinh Nguyen <[email protected]>

---
 drivers/usb/host/xhci-plat.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/usb/host/xhci-plat.h +3 -1

index 2d15386f2c50..6475130eac4b 100644
@@ -8,7 +8,9 @@
 #ifndef _XHCI_PLAT_H
 #define _XHCI_PLAT_H
 
-#include "xhci.h"	/* for hcd_to_xhci() */
+struct device;
+struct platform_device;
+struct usb_hcd;
 

Quoted 5 lines

drivers/usb/host/xhci-plat.h +0 -0

 struct xhci_plat_priv {
 	const char *firmware_name;

Signature · 1 line

2.28.0

Seems to break the build :(

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

---
 drivers/usb/dwc3/core.c   | 90 +++++++++++++++++----------------------
 drivers/usb/dwc3/core.h   |  1 +
 drivers/usb/dwc3/gadget.c |  2 +
 drivers/usb/dwc3/host.c   | 27 ++++++++++++
 4 files changed, 68 insertions(+), 52 deletions(-)

drivers/usb/dwc3/core.c +38 -52

index 31684cdaaae3..100041320e8d 100644
@@ -104,6 +104,27 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
 	return 0;
 }
 
+void dwc3_enable_susphy(struct dwc3 *dwc, bool enable)
+{
+	u32 reg;
+
+	reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
+	if (enable && !dwc->dis_u3_susphy_quirk)
+		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
+	else
+		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
+
+	dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+	reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+	if (enable && !dwc->dis_u2_susphy_quirk)
+		reg |= DWC3_GUSB2PHYCFG_SUSPHY;
+	else
+		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+
+	dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+}
+
 void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
 {
 	u32 reg;

@@ -585,11 +606,8 @@ static int dwc3_core_ulpi_init(struct dwc3 *dwc)
  */
 static int dwc3_phy_setup(struct dwc3 *dwc)
 {
-	unsigned int hw_mode;
 	u32 reg;
 
-	hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
-
 	reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
 
 	/*

@@ -599,21 +617,16 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	reg &= ~DWC3_GUSB3PIPECTL_UX_EXIT_PX;
 
 	/*
-	 * Above 1.94a, it is recommended to set DWC3_GUSB3PIPECTL_SUSPHY
-	 * to '0' during coreConsultant configuration. So default value
-	 * will be '0' when the core is reset. Application needs to set it
-	 * to '1' after the core initialization is completed.
-	 */
-	if (!DWC3_VER_IS_WITHIN(DWC3, ANY, 194A))
-		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
-
-	/*
-	 * For DRD controllers, GUSB3PIPECTL.SUSPENDENABLE must be cleared after
-	 * power-on reset, and it can be set after core initialization, which is
-	 * after device soft-reset during initialization.
+	 * Above DWC_usb3.0 1.94a, it is recommended to set
+	 * DWC3_GUSB3PIPECTL_SUSPHY to '0' during coreConsultant configuration.
+	 * So default value will be '0' when the core is reset. Application
+	 * needs to set it to '1' after the core initialization is completed.
+	 *
+	 * Similarly for DRD controllers, GUSB3PIPECTL.SUSPENDENABLE must be
+	 * cleared after power-on reset, and it can be set after core
+	 * initialization.
 	 */
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD)
-		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
+	reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
 
 	if (dwc->u2ss_inp3_quirk)
 		reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK;

@@ -639,9 +652,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	if (dwc->tx_de_emphasis_quirk)
 		reg |= DWC3_GUSB3PIPECTL_TX_DEEPH(dwc->tx_de_emphasis);
 
-	if (dwc->dis_u3_susphy_quirk)
-		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
-
 	if (dwc->dis_del_phy_power_chg_quirk)
 		reg &= ~DWC3_GUSB3PIPECTL_DEPOCHANGE;
 

@@ -689,24 +699,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	}
 
 	/*
-	 * Above 1.94a, it is recommended to set DWC3_GUSB2PHYCFG_SUSPHY to
-	 * '0' during coreConsultant configuration. So default value will
-	 * be '0' when the core is reset. Application needs to set it to
-	 * '1' after the core initialization is completed.
-	 */
-	if (!DWC3_VER_IS_WITHIN(DWC3, ANY, 194A))
-		reg |= DWC3_GUSB2PHYCFG_SUSPHY;
-
-	/*
-	 * For DRD controllers, GUSB2PHYCFG.SUSPHY must be cleared after
-	 * power-on reset, and it can be set after core initialization, which is
-	 * after device soft-reset during initialization.
+	 * Above DWC_usb3.0 1.94a, it is recommended to set
+	 * DWC3_GUSB2PHYCFG_SUSPHY to '0' during coreConsultant configuration.
+	 * So default value will be '0' when the core is reset. Application
+	 * needs to set it to '1' after the core initialization is completed.
+	 *
+	 * Similarly for DRD controllers, GUSB2PHYCFG.SUSPHY must be cleared
+	 * after power-on reset, and it can be set after core initialization.
 	 */
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD)
-		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
-
-	if (dwc->dis_u2_susphy_quirk)
-		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+	reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
 	if (dwc->dis_enblslpm_quirk)
 		reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;

@@ -1227,21 +1228,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
 	if (ret)
 		goto err_exit_phy;
 
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD &&
-	    !DWC3_VER_IS_WITHIN(DWC3, ANY, 194A)) {
-		if (!dwc->dis_u3_susphy_quirk) {
-			reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-			reg |= DWC3_GUSB3PIPECTL_SUSPHY;
-			dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-		}
-
-		if (!dwc->dis_u2_susphy_quirk) {
-			reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-			reg |= DWC3_GUSB2PHYCFG_SUSPHY;
-			dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-		}
-	}
-
 	dwc3_core_setup_global_control(dwc);
 	dwc3_core_num_eps(dwc);
 

drivers/usb/dwc3/core.h +1 -0

index 7e80dd3d466b..180dd8d29287 100644
@@ -1580,6 +1580,7 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc);
 void dwc3_event_buffers_cleanup(struct dwc3 *dwc);
 
 int dwc3_core_soft_reset(struct dwc3 *dwc);
+void dwc3_enable_susphy(struct dwc3 *dwc, bool enable);
 
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);

drivers/usb/dwc3/gadget.c +2 -0

index 4df2661f6675..f94f68f1e7d2 100644
@@ -2924,6 +2924,7 @@ static int __dwc3_gadget_start(struct dwc3 *dwc)
 	dwc3_ep0_out_start(dwc);
 
 	dwc3_gadget_enable_irq(dwc);
+	dwc3_enable_susphy(dwc, true);
 
 	return 0;
 

@@ -4690,6 +4691,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
 	if (!dwc->gadget)
 		return;
 
+	dwc3_enable_susphy(dwc, false);
 	usb_del_gadget(dwc->gadget);
 	dwc3_gadget_free_endpoints(dwc);
 	usb_put_gadget(dwc->gadget);

drivers/usb/dwc3/host.c +27 -0

index 0204787df81d..a171b27a7845 100644
@@ -10,10 +10,13 @@
 #include <linux/irq.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
 #include "../host/xhci-port.h"
 #include "../host/xhci-ext-caps.h"
 #include "../host/xhci-caps.h"
+#include "../host/xhci-plat.h"
 #include "core.h"
 
 #define XHCI_HCSPARAMS1		0x4

@@ -57,6 +60,24 @@ static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
 	}
 }
 
+static void dwc3_xhci_plat_start(struct usb_hcd *hcd)
+{
+	struct platform_device *pdev;
+	struct dwc3 *dwc;
+
+	if (!usb_hcd_is_primary_hcd(hcd))
+		return;
+
+	pdev = to_platform_device(hcd->self.controller);
+	dwc = dev_get_drvdata(pdev->dev.parent);
+
+	dwc3_enable_susphy(dwc, true);
+}
+
+static const struct xhci_plat_priv dwc3_xhci_plat_quirk = {
+	.plat_start = dwc3_xhci_plat_start,
+};
+
 static void dwc3_host_fill_xhci_irq_res(struct dwc3 *dwc,
 					int irq, char *name)
 {

@@ -167,6 +188,11 @@ int dwc3_host_init(struct dwc3 *dwc)
 		}
 	}
 
+	ret = platform_device_add_data(xhci, &dwc3_xhci_plat_quirk,
+				       sizeof(struct xhci_plat_priv));
+	if (ret)
+		goto err;
+
 	ret = platform_device_add(xhci);
 	if (ret) {
 		dev_err(dwc->dev, "failed to register xHCI device\n");

@@ -192,6 +218,7 @@ void dwc3_host_exit(struct dwc3 *dwc)
 	if (dwc->sys_wakeup)
 		device_init_wakeup(&dwc->xhci->dev, false);
 
+	dwc3_enable_susphy(dwc, false);
 	platform_device_unregister(dwc->xhci);
 	dwc->xhci = NULL;
 }

Hello Thinh,

Quoted 18 lines · Thinh Nguyen

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Quoted 7 lines

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

This patch is causing system suspend failures on TI AM62 platforms [1]

I will try to explain why.
Before this patch, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during initialization and even during re-initialization after a system suspend/resume.

These bits are required to be set for system suspend/resume to work correctly on AM62 platforms.

After this patch, the bits are only set when Host controller starts or when Gadget driver starts.

On AM62 platform we have 2 USB controllers, one in Host and one in Dual role. Just after boot, for the Host controller we have the 2 SUSPHY bits set but for the Dual-Role controller, as no role has started the 2 SUSPHY bits are not set. Thus system suspend resume will fail.

On the other hand, if we load a gadget driver just after boot then both controllers have the 2 SUSPHY bits set and system suspend resume works for the first time.
However, after system resume, the core is re-initialized so the 2 SUSPHY bits are cleared for both controllers. For host controller it is never set again. For gadget controller as gadget start is called, the 2 SUSPHY bits are set again. The second system suspend resume will still fail as one controller (Host) doesn't have the 2 SUSPHY bits set.

To summarize, the existing solution is not sufficient for us to have a reliable behavior. We need the 2 SUSPHY bits to be set regardless of what role we are in or whether the role has started or not.

My suggestion is to move back the SUSPHY enable to end of dwc3_core_init(). Then if SUSPHY needs to be disabled for DRD role switching, it should be disabled and enabled exactly there.

What do you suggest?

[1] - https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/[email protected]/__;!!A4F2R9G_pg!Y10q3gwCzryOoiXpk6DMGn74iFQIg6GloY10J16kWCbqwgS1Algo5HRg05vm38dMw8n47qmKpqJlyXt9Kqlm$

Hi Roger,

Quoted 36 lines · Roger Quadros

Hello Thinh,

Quoted 18 lines · Thinh Nguyen

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Quoted 7 lines

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

This patch is causing system suspend failures on TI AM62 platforms [1]

I will try to explain why.
Before this patch, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during initialization and even during re-initialization after a system suspend/resume.

Quoted 2 lines

These bits are required to be set for system suspend/resume to work correctly on AM62 platforms.

Is it only for suspend or both suspend and resume?

Quoted 23 lines

After this patch, the bits are only set when Host controller starts or when Gadget driver starts.

On AM62 platform we have 2 USB controllers, one in Host and one in Dual role. Just after boot, for the Host controller we have the 2 SUSPHY bits set but for the Dual-Role controller, as no role has started the 2 SUSPHY bits are not set. Thus system suspend resume will fail.

On the other hand, if we load a gadget driver just after boot then both controllers have the 2 SUSPHY bits set and system suspend resume works for the first time.
However, after system resume, the core is re-initialized so the 2 SUSPHY bits are cleared for both controllers. For host controller it is never set again. For gadget controller as gadget start is called, the 2 SUSPHY bits are set again. The second system suspend resume will still fail as one controller (Host) doesn't have the 2 SUSPHY bits set.

To summarize, the existing solution is not sufficient for us to have a reliable behavior. We need the 2 SUSPHY bits to be set regardless of what role we are in or whether the role has started or not.

Quoted 8 lines

My suggestion is to move back the SUSPHY enable to end of dwc3_core_init(). Then if SUSPHY needs to be disabled for DRD role switching, it should be disabled and enabled exactly there.

What do you suggest?

[1] - https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/[email protected]/__;!!A4F2R9G_pg!Y10q3gwCzryOoiXpk6DMGn74iFQIg6GloY10J16kWCbqwgS1Algo5HRg05vm38dMw8n47qmKpqJlyXt9Kqlm$

Thanks for reporting the issue.

This is quite an interesting behavior. As you said, we will need to isolate this change to only during DRD role switch.

We may not necessarily just enable at the end of dwc3_core_init() since that would keep the SUSPHY bits on during the DRD role switch. If this issue only occurs before suspend, perhaps we can check and set these bits during suspend or dwc3_core_exit() instead?

Quoted 39 lines · Thinh Nguyen

Hi Roger,

Quoted 36 lines · Roger Quadros

Hello Thinh,

Quoted 18 lines · Thinh Nguyen

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Quoted 7 lines

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

This patch is causing system suspend failures on TI AM62 platforms [1]

I will try to explain why.
Before this patch, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during initialization and even during re-initialization after a system suspend/resume.

Quoted 4 lines

Quoted 2 lines

These bits are required to be set for system suspend/resume to work correctly on AM62 platforms.

Is it only for suspend or both suspend and resume?

I'm sure about suspend. It is not possible to toggle those bits while in system suspend so we can't really say if it is required exclusively for system resume or not.

Quoted 34 lines

Quoted 23 lines

After this patch, the bits are only set when Host controller starts or when Gadget driver starts.

On AM62 platform we have 2 USB controllers, one in Host and one in Dual role. Just after boot, for the Host controller we have the 2 SUSPHY bits set but for the Dual-Role controller, as no role has started the 2 SUSPHY bits are not set. Thus system suspend resume will fail.

On the other hand, if we load a gadget driver just after boot then both controllers have the 2 SUSPHY bits set and system suspend resume works for the first time.
However, after system resume, the core is re-initialized so the 2 SUSPHY bits are cleared for both controllers. For host controller it is never set again. For gadget controller as gadget start is called, the 2 SUSPHY bits are set again. The second system suspend resume will still fail as one controller (Host) doesn't have the 2 SUSPHY bits set.

To summarize, the existing solution is not sufficient for us to have a reliable behavior. We need the 2 SUSPHY bits to be set regardless of what role we are in or whether the role has started or not.

Quoted 8 lines

My suggestion is to move back the SUSPHY enable to end of dwc3_core_init(). Then if SUSPHY needs to be disabled for DRD role switching, it should be disabled and enabled exactly there.

What do you suggest?

[1] - https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/[email protected]/__;!!A4F2R9G_pg!Y10q3gwCzryOoiXpk6DMGn74iFQIg6GloY10J16kWCbqwgS1Algo5HRg05vm38dMw8n47qmKpqJlyXt9Kqlm$

Thanks for reporting the issue.

Quoted 7 lines

This is quite an interesting behavior. As you said, we will need to isolate this change to only during DRD role switch.

We may not necessarily just enable at the end of dwc3_core_init() since that would keep the SUSPHY bits on during the DRD role switch. If this issue only occurs before suspend, perhaps we can check and set these bits during suspend or dwc3_core_exit() instead?

dwc3_core_exit() is not always called in the system suspend path so it may not be sufficient.

Any issues if we set this these bits at the end of dwc3_suspend_common() irrespective of runtime suspend or system suspend and operating role?

And should we restore these bits in dwc3_resume_common() to the state they were before dwc3_suspend_common()?

Quoted 92 lines · Roger Quadros

Quoted 39 lines · Thinh Nguyen

Hi Roger,

Quoted 36 lines · Roger Quadros

Hello Thinh,

Quoted 18 lines · Thinh Nguyen

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Quoted 7 lines

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

This patch is causing system suspend failures on TI AM62 platforms [1]

I will try to explain why.
Before this patch, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during initialization and even during re-initialization after a system suspend/resume.

Quoted 4 lines

Quoted 2 lines

These bits are required to be set for system suspend/resume to work correctly on AM62 platforms.

Is it only for suspend or both suspend and resume?

I'm sure about suspend. It is not possible to toggle those bits while in system suspend so we can't really say if it is required exclusively for system resume or not.

Quoted 34 lines

Quoted 23 lines

After this patch, the bits are only set when Host controller starts or when Gadget driver starts.

On AM62 platform we have 2 USB controllers, one in Host and one in Dual role. Just after boot, for the Host controller we have the 2 SUSPHY bits set but for the Dual-Role controller, as no role has started the 2 SUSPHY bits are not set. Thus system suspend resume will fail.

On the other hand, if we load a gadget driver just after boot then both controllers have the 2 SUSPHY bits set and system suspend resume works for the first time.
However, after system resume, the core is re-initialized so the 2 SUSPHY bits are cleared for both controllers. For host controller it is never set again. For gadget controller as gadget start is called, the 2 SUSPHY bits are set again. The second system suspend resume will still fail as one controller (Host) doesn't have the 2 SUSPHY bits set.

To summarize, the existing solution is not sufficient for us to have a reliable behavior. We need the 2 SUSPHY bits to be set regardless of what role we are in or whether the role has started or not.

Quoted 8 lines

My suggestion is to move back the SUSPHY enable to end of dwc3_core_init(). Then if SUSPHY needs to be disabled for DRD role switching, it should be disabled and enabled exactly there.

What do you suggest?

[1] - https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/[email protected]/__;!!A4F2R9G_pg!Y10q3gwCzryOoiXpk6DMGn74iFQIg6GloY10J16kWCbqwgS1Algo5HRg05vm38dMw8n47qmKpqJlyXt9Kqlm$

Thanks for reporting the issue.

Quoted 7 lines

This is quite an interesting behavior. As you said, we will need to isolate this change to only during DRD role switch.

We may not necessarily just enable at the end of dwc3_core_init() since that would keep the SUSPHY bits on during the DRD role switch. If this issue only occurs before suspend, perhaps we can check and set these bits during suspend or dwc3_core_exit() instead?

Quoted 5 lines

dwc3_core_exit() is not always called in the system suspend path so it may not be sufficient.

Any issues if we set this these bits at the end of dwc3_suspend_common() irrespective of runtime suspend or system suspend and operating role?

There should be no issue at this point. The problem occurs during initialization that involves initializing the usb role.

Quoted 3 lines

And should we restore these bits in dwc3_resume_common() to the state they were before dwc3_suspend_common()?

Sounds good to me! Would you mind send a fix patch?

Hello Thinh,

Quoted 18 lines · Thinh Nguyen

GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout.

The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant.

This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers.

Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes.

Quoted 7 lines

Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to.

Cc [email protected]

Fixes 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")

Signed-off-by Thinh Nguyen <[email protected]>

This patch is causing system suspend failures on TI AM62 platforms [1]

I will try to explain why.
Before this patch, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during initialization and even during re-initialization after a system suspend/resume.

These bits are required to be set for system suspend/resume to work correctly on AM62 platforms.

After this patch, the bits are only set when Host controller starts or when Gadget driver starts.

On AM62 platform we have 2 USB controllers, one in Host and one in Dual role. Just after boot, for the Host controller we have the 2 SUSPHY bits set but for the Dual-Role controller, as no role has started the 2 SUSPHY bits are not set. Thus system suspend resume will fail.

On the other hand, if we load a gadget driver just after boot then both controllers have the 2 SUSPHY bits set and system suspend resume works for the first time.
However, after system resume, the core is re-initialized so the 2 SUSPHY bits are cleared for both controllers. For host controller it is never set again. For gadget controller as gadget start is called, the 2 SUSPHY bits are set again. The second system suspend resume will still fail as one controller (Host) doesn't have the 2 SUSPHY bits set.

To summarize, the existing solution is not sufficient for us to have a reliable behavior. We need the 2 SUSPHY bits to be set regardless of what role we are in or whether the role has started or not.

My suggestion is to move back the SUSPHY enable to end of dwc3_core_init(). Then if SUSPHY needs to be disabled for DRD role switching, it should be disabled and enabled exactly there.

What do you suggest?

[1] - https://lore.kernel.org/linux-arm-kernel/[email protected]/

Signature · 2 lines

cheers,
-roger

Quoted 235 lines

---
 drivers/usb/dwc3/core.c   | 90 +++++++++++++++++----------------------
 drivers/usb/dwc3/core.h   |  1 +
 drivers/usb/dwc3/gadget.c |  2 +
 drivers/usb/dwc3/host.c   | 27 ++++++++++++
 4 files changed, 68 insertions(+), 52 deletions(-)

drivers/usb/dwc3/core.c +38 -52

index 31684cdaaae3..100041320e8d 100644
@@ -104,6 +104,27 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
 	return 0;
 }
 
+void dwc3_enable_susphy(struct dwc3 *dwc, bool enable)
+{
+	u32 reg;
+
+	reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
+	if (enable && !dwc->dis_u3_susphy_quirk)
+		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
+	else
+		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
+
+	dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+	reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+	if (enable && !dwc->dis_u2_susphy_quirk)
+		reg |= DWC3_GUSB2PHYCFG_SUSPHY;
+	else
+		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+
+	dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+}
+
 void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
 {
 	u32 reg;

@@ -585,11 +606,8 @@ static int dwc3_core_ulpi_init(struct dwc3 *dwc)
  */
 static int dwc3_phy_setup(struct dwc3 *dwc)
 {
-	unsigned int hw_mode;
 	u32 reg;
 
-	hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
-
 	reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
 
 	/*

@@ -599,21 +617,16 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	reg &= ~DWC3_GUSB3PIPECTL_UX_EXIT_PX;
 
 	/*
-	 * Above 1.94a, it is recommended to set DWC3_GUSB3PIPECTL_SUSPHY
-	 * to '0' during coreConsultant configuration. So default value
-	 * will be '0' when the core is reset. Application needs to set it
-	 * to '1' after the core initialization is completed.
-	 */
-	if (!DWC3_VER_IS_WITHIN(DWC3, ANY, 194A))
-		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
-
-	/*
-	 * For DRD controllers, GUSB3PIPECTL.SUSPENDENABLE must be cleared after
-	 * power-on reset, and it can be set after core initialization, which is
-	 * after device soft-reset during initialization.
+	 * Above DWC_usb3.0 1.94a, it is recommended to set
+	 * DWC3_GUSB3PIPECTL_SUSPHY to '0' during coreConsultant configuration.
+	 * So default value will be '0' when the core is reset. Application
+	 * needs to set it to '1' after the core initialization is completed.
+	 *
+	 * Similarly for DRD controllers, GUSB3PIPECTL.SUSPENDENABLE must be
+	 * cleared after power-on reset, and it can be set after core
+	 * initialization.
 	 */
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD)
-		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
+	reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
 
 	if (dwc->u2ss_inp3_quirk)
 		reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK;

@@ -639,9 +652,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	if (dwc->tx_de_emphasis_quirk)
 		reg |= DWC3_GUSB3PIPECTL_TX_DEEPH(dwc->tx_de_emphasis);
 
-	if (dwc->dis_u3_susphy_quirk)
-		reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
-
 	if (dwc->dis_del_phy_power_chg_quirk)
 		reg &= ~DWC3_GUSB3PIPECTL_DEPOCHANGE;
 

@@ -689,24 +699,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	}
 
 	/*
-	 * Above 1.94a, it is recommended to set DWC3_GUSB2PHYCFG_SUSPHY to
-	 * '0' during coreConsultant configuration. So default value will
-	 * be '0' when the core is reset. Application needs to set it to
-	 * '1' after the core initialization is completed.
-	 */
-	if (!DWC3_VER_IS_WITHIN(DWC3, ANY, 194A))
-		reg |= DWC3_GUSB2PHYCFG_SUSPHY;
-
-	/*
-	 * For DRD controllers, GUSB2PHYCFG.SUSPHY must be cleared after
-	 * power-on reset, and it can be set after core initialization, which is
-	 * after device soft-reset during initialization.
+	 * Above DWC_usb3.0 1.94a, it is recommended to set
+	 * DWC3_GUSB2PHYCFG_SUSPHY to '0' during coreConsultant configuration.
+	 * So default value will be '0' when the core is reset. Application
+	 * needs to set it to '1' after the core initialization is completed.
+	 *
+	 * Similarly for DRD controllers, GUSB2PHYCFG.SUSPHY must be cleared
+	 * after power-on reset, and it can be set after core initialization.
 	 */
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD)
-		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
-
-	if (dwc->dis_u2_susphy_quirk)
-		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+	reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
 	if (dwc->dis_enblslpm_quirk)
 		reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;

@@ -1227,21 +1228,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
 	if (ret)
 		goto err_exit_phy;
 
-	if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD &&
-	    !DWC3_VER_IS_WITHIN(DWC3, ANY, 194A)) {
-		if (!dwc->dis_u3_susphy_quirk) {
-			reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-			reg |= DWC3_GUSB3PIPECTL_SUSPHY;
-			dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-		}
-
-		if (!dwc->dis_u2_susphy_quirk) {
-			reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-			reg |= DWC3_GUSB2PHYCFG_SUSPHY;
-			dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-		}
-	}
-
 	dwc3_core_setup_global_control(dwc);
 	dwc3_core_num_eps(dwc);
 

drivers/usb/dwc3/core.h +1 -0

index 7e80dd3d466b..180dd8d29287 100644
@@ -1580,6 +1580,7 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc);
 void dwc3_event_buffers_cleanup(struct dwc3 *dwc);
 
 int dwc3_core_soft_reset(struct dwc3 *dwc);
+void dwc3_enable_susphy(struct dwc3 *dwc, bool enable);
 
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);

drivers/usb/dwc3/gadget.c +2 -0

index 4df2661f6675..f94f68f1e7d2 100644
@@ -2924,6 +2924,7 @@ static int __dwc3_gadget_start(struct dwc3 *dwc)
 	dwc3_ep0_out_start(dwc);
 
 	dwc3_gadget_enable_irq(dwc);
+	dwc3_enable_susphy(dwc, true);
 
 	return 0;
 

@@ -4690,6 +4691,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
 	if (!dwc->gadget)
 		return;
 
+	dwc3_enable_susphy(dwc, false);
 	usb_del_gadget(dwc->gadget);
 	dwc3_gadget_free_endpoints(dwc);
 	usb_put_gadget(dwc->gadget);

drivers/usb/dwc3/host.c +26 -0

index 0204787df81d..a171b27a7845 100644
@@ -10,10 +10,13 @@
 #include <linux/irq.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
 #include "../host/xhci-port.h"
 #include "../host/xhci-ext-caps.h"
 #include "../host/xhci-caps.h"
+#include "../host/xhci-plat.h"
 #include "core.h"
 
 #define XHCI_HCSPARAMS1		0x4

@@ -57,6 +60,24 @@ static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
 	}
 }
 
+static void dwc3_xhci_plat_start(struct usb_hcd *hcd)
+{
+	struct platform_device *pdev;
+	struct dwc3 *dwc;
+
+	if (!usb_hcd_is_primary_hcd(hcd))
+		return;
+
+	pdev = to_platform_device(hcd->self.controller);
+	dwc = dev_get_drvdata(pdev->dev.parent);
+
+	dwc3_enable_susphy(dwc, true);
+}
+
+static const struct xhci_plat_priv dwc3_xhci_plat_quirk = {
+	.plat_start = dwc3_xhci_plat_start,
+};
+
 static void dwc3_host_fill_xhci_irq_res(struct dwc3 *dwc,
 					int irq, char *name)
 {

@@ -167,6 +188,11 @@ int dwc3_host_init(struct dwc3 *dwc)
 		}
 	}
 
+	ret = platform_device_add_data(xhci, &dwc3_xhci_plat_quirk,
+				       sizeof(struct xhci_plat_priv));
+	if (ret)
+		goto err;
+
 	ret = platform_device_add(xhci);
 	if (ret) {
 		dev_err(dwc->dev, "failed to register xHCI device\n");

drivers/usb/dwc3/host.c void dwc3_host_exit(struct dwc3 *dwc) · line 224

Quoted 7 lines

drivers/usb/dwc3/host.c +1 -0

@@ -192,6 +218,7 @@ void dwc3_host_exit(struct dwc3 *dwc)
 	if (dwc->sys_wakeup)
 		device_init_wakeup(&dwc->xhci->dev, false);
 
+	dwc3_enable_susphy(dwc, false);
 	platform_device_unregister(dwc->xhci);
 	dwc->xhci = NULL;
 }

This patch seems to break system suspend on at least the Rockchip RK3566 platform. I noticed that I was no longer able to suspend and git bisect led me to this patch.

My kernel message log shows the following, at which point it freezes and does not allow me to resume from suspend:

[   27.235049] PM: suspend entry (deep)
[   27.871641] Filesystems sync: 0.636 seconds
[   27.885320] Freezing user space processes
[   27.886932] Freezing user space processes completed (elapsed 0.001 seconds)
[   27.887642] OOM killer disabled.
[   27.887981] Freezing remaining freezable tasks
[   27.889655] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

Thank you,
Chris

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 30 lines

Hi,

Quoted 16 lines · Chris Morgan

This patch seems to break system suspend on at least the Rockchip RK3566 platform. I noticed that I was no longer able to suspend and git bisect led me to this patch.

My kernel message log shows the following, at which point it freezes and does not allow me to resume from suspend:

[   27.235049] PM: suspend entry (deep)
[   27.871641] Filesystems sync: 0.636 seconds
[   27.885320] Freezing user space processes
[   27.886932] Freezing user space processes completed (elapsed 0.001 seconds)
[   27.887642] OOM killer disabled.
[   27.887981] Freezing remaining freezable tasks
[   27.889655] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

Quoted 2 lines

Thank you,
Chris

Did you try out Roger's fix?
705e3ce37bcc ("usb: dwc3: core: Fix system suspend on TI AM62 platforms")

https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=705e3ce37bccdf2ed6f848356ff355f480d51a91__;!!A4F2R9G_pg!ZXQdR2uLykSD67_3JSm0RZHuyJ7IVnw5EvmYvLnPsf3dDEilv5ZgHD9GX7gZr52t0H7oFKifzAEhbdK8EGYzmSji2UI$

BR,
Thinh

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Thanks,
Thinh

Quoted 32 lines · Thinh Nguyen

Quoted 30 lines

Hi,

Quoted 16 lines · Chris Morgan

This patch seems to break system suspend on at least the Rockchip RK3566 platform. I noticed that I was no longer able to suspend and git bisect led me to this patch.

My kernel message log shows the following, at which point it freezes and does not allow me to resume from suspend:

[   27.235049] PM: suspend entry (deep)
[   27.871641] Filesystems sync: 0.636 seconds
[   27.885320] Freezing user space processes
[   27.886932] Freezing user space processes completed (elapsed 0.001 seconds)
[   27.887642] OOM killer disabled.
[   27.887981] Freezing remaining freezable tasks
[   27.889655] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

Quoted 2 lines

Thank you,
Chris

Did you try out Roger's fix?
705e3ce37bcc ("usb: dwc3: core: Fix system suspend on TI AM62 platforms")

https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=705e3ce37bccdf2ed6f848356ff355f480d51a91__;!!A4F2R9G_pg!ZXQdR2uLykSD67_3JSm0RZHuyJ7IVnw5EvmYvLnPsf3dDEilv5ZgHD9GX7gZr52t0H7oFKifzAEhbdK8EGYzmSji2UI$

BR,
Thinh

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

cheers,
-roger

Quoted 36 lines

Thanks,
Thinh

Quoted 32 lines · Thinh Nguyen

Quoted 30 lines

Hi,

Quoted 16 lines · Chris Morgan

This patch seems to break system suspend on at least the Rockchip RK3566 platform. I noticed that I was no longer able to suspend and git bisect led me to this patch.

My kernel message log shows the following, at which point it freezes and does not allow me to resume from suspend:

[   27.235049] PM: suspend entry (deep)
[   27.871641] Filesystems sync: 0.636 seconds
[   27.885320] Freezing user space processes
[   27.886932] Freezing user space processes completed (elapsed 0.001 seconds)
[   27.887642] OOM killer disabled.
[   27.887981] Freezing remaining freezable tasks
[   27.889655] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

Quoted 2 lines

Thank you,
Chris

Did you try out Roger's fix?
705e3ce37bcc ("usb: dwc3: core: Fix system suspend on TI AM62 platforms")

https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=705e3ce37bccdf2ed6f848356ff355f480d51a91__;!!A4F2R9G_pg!ZXQdR2uLykSD67_3JSm0RZHuyJ7IVnw5EvmYvLnPsf3dDEilv5ZgHD9GX7gZr52t0H7oFKifzAEhbdK8EGYzmSji2UI$

BR,
Thinh

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Thank you,
Chris

Quoted 35 lines · Chris Morgan

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Quoted 6 lines

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Yes, any data is useful.

Quoted 1 line

Quoted 2 lines

Thank you,
Chris

Can you help answer the other bullet questions I have previously.

Thanks,
Thinh

Quoted 49 lines · Thinh Nguyen

Quoted 35 lines · Chris Morgan

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Quoted 6 lines

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Yes, any data is useful.

Quoted 3 lines

Thank you,
Chris

Quoted 4 lines

Can you help answer the other bullet questions I have previously.

Thanks,
Thinh

I have 2 ports, here is a dump of each:

Hi Chris,

Quoted 52 lines · Chris Morgan

Quoted 51 lines · Thinh Nguyen

Quoted 35 lines · Chris Morgan

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Quoted 6 lines

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Yes, any data is useful.

Quoted 3 lines

Thank you,
Chris

Can you help answer the other bullet questions I have previously.

Quoted 4 lines

Quoted 2 lines

Thanks,
Thinh

I have 2 ports, here is a dump of each:

Did you try this patch [1]. Does it fix the issue for you?

[1] https://lore.kernel.org/all/[email protected]/

Signature · 2 lines

cheers,
-roger

Quoted 51 lines · Thinh Nguyen

Quoted 35 lines · Chris Morgan

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Quoted 6 lines

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Yes, any data is useful.

Quoted 3 lines

Thank you,
Chris

Can you help answer the other bullet questions I have previously.

Quoted 2 lines

Thanks,
Thinh

I have 2 ports, here is a dump of each:

usb@fcc00000:

fd000000:

Quoted 52 lines · Chris Morgan

Quoted 51 lines · Thinh Nguyen

Quoted 35 lines · Chris Morgan

Quoted 19 lines · Roger Quadros

Hi Chris,

Quoted 8 lines · Thinh Nguyen

Hi,

Quoted 4 lines · Chris Morgan

Sorry, to be specific it was the fix that causes the issues I'm now observing. When I explicitly revert commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 things start working again for me. With that commit in place, however, suspend fails for me.

Quoted 7 lines

Ok, Roger's patch is causing issue on your platform and the $subject patch? Can you provide more details on your test sequence?

* What does "no longer able to suspend" mean exactly (what error?)
* What mode is your usb controller?
* Is there any device connected while going into suspend?
* Can you provide dwc3 regdump?

Quoted 8 lines

Commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 will enable DWC3_GUSB2PHYCFG_SUSPHY in DWC3_GUSB2PHYCFG(i)
and DWC3_GUSB3PIPECTL_SUSPHY in DWC3_GUSB3PIPECTL(i) during system suspend path, unless snps,dis_u2_susphy_quirk or snps,dis_u3_susphy_quirk is set.

I see rK356x.dtsi has snps,dis_u2_susphy_quirk; Does adding snps,dis_u3_susphy_quirk resolve the issue?

I'm afraid it does not fix the issue. Specifically when I do "systemctl suspend" the device begins to suspend but freezes with the kernel log output via serial console listed previously. Note I have console enabled in suspend. Additionally button input no longer works at this point.

Quoted 6 lines

Specifically, I'm testing this with the Anbernic RG353P device based on the Rockchip RK3566 SoC, in case you're curious.

I'm not able to get you a register dump post suspend attempt as the system completely freezes, however I can get you a dump prior to suspend if that will help?

Yes, any data is useful.

Quoted 3 lines

Thank you,
Chris

Can you help answer the other bullet questions I have previously.

Quoted 8 lines

Quoted 2 lines

Thanks,
Thinh

I have 2 ports, here is a dump of each:

usb@fcc00000:

fd000000:

Thanks for the dumps! They're helpful. Looks like the fcc00000 is device mode and operating in usb2 speed only, and the fd000000 is host.

Can you help narrow down the problems by checking these:

When you set the snps,dis_u3_susphy_quirk, did you set it to both controllers?

Which controller suspend causes the problem? The host or the device or both? you can check by unbind the driver for each 1 at a time to prevent suspend. e.g.:

 # echo usb@fcc00000 > /sys/bus/platform/drivers/dwc3/unbind
 # echo usb@fd000000 > /sys/bus/platform/drivers/dwc3/unbind

Thanks,
Thinh

I'm no longer able to replicate the issue, so I'm guessing some subsequent fixes solved it. I thought I tested them all but maybe I missed one.

Thank you.