Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759357AbcCDSXd (ORCPT ); Fri, 4 Mar 2016 13:23:33 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:33470 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255AbcCDSXb (ORCPT ); Fri, 4 Mar 2016 13:23:31 -0500 From: Douglas Anderson To: johnyoun@synopsys.com, balbi@kernel.org, Heiko Stuebner Cc: linux@mniewoehner.de, caesar.upstream@gmail.com, huangtao@rock-chips.com, repk@triplefau.lt, stefan.wahren@i2se.com, Julius Werner , Douglas Anderson , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset() Date: Fri, 4 Mar 2016 10:23:05 -0800 Message-Id: <1457115786-11370-1-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.7.0.rc3.207.g0ac5344 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 48 >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 --- 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