On 3/4/2016 10:23 AM, Douglas Anderson wrote: > 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 <diand...@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; > } > >
Hi Doug, Thanks for tracking this down. Caesar, Could you test these two commits on your rk3066 platform? And also see if it works after reverting bd84f4ae9986? Thanks, John