[RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

[Douglas Anderson <dianders@chromium.org>]

>From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent.  Let's add it.

In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835").  Though I
could never reproduce the problems on my board, this might also allow us
to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
dr_mode").

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
 drivers/usb/dwc2/core.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 5e5a0f135b5a..8710b2d3e770 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 		}
 	} while (!(greset & GRSTCTL_AHBIDLE));
 
+	/*
+	 * Sleep for 10-15 ms after the reset to let it finish.
+	 *
+	 * It's been confirmed on at least one version of the controller
+	 * that this is a requirement that this is a requirement in order for
+	 * everything to settle.  Specifically if you:
+	 * - change GNPTXFSIZ or HPTXFSIZ before the reset
+	 * - do the reset
+	 * - read GNPTXFSIZ or HPTXFSIZ in a loop
+	 * ...you'll find that it takes almost exactly 10 ms for the registers
+	 * to return to their reset defaults.
+	 *
+	 * Note that it's possible that this 10 ms is the time referred to
+	 * in "Host Initialization" where it says to "Wait at least 10 ms for
+	 * the reset process to complete".  In "Device Initialization" there
+	 * is also talk of a reset lasting 10 ms.  That may be the source of
+	 * this delay.
+	 */
+	usleep_range(10000, 15000);
+
 	return 0;
 }
 
-- 
2.7.0.rc3.207.g0ac5344