Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
From: Michael Niewoehner <linux@mniewoehner.de>
In-Reply-To: <1457115786-11370-1-git-send-email-dianders@chromium.org>
Date: Fri, 4 Mar 2016 23:54:27 +0100
Cc: johnyoun@synopsys.com, balbi@kernel.org, Heiko Stuebner <heiko@sntech.de>,
        caesar.upstream@gmail.com, huangtao@rock-chips.com, repk@triplefau.lt,
        stefan.wahren@i2se.com, Julius Werner <jwerner@chromium.org>,
        gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8BIT
Message-Id: <58FE77DF-E10D-4E16-8FC7-2D13C8037EFB@mniewoehner.de>
References: <1457115786-11370-1-git-send-email-dianders@chromium.org>
To: Douglas Anderson <dianders@chromium.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2360
Lines: 63

Hi Douglas,

Am 04.03.2016 um 19:23 schrieb 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>

Tested-by: Michael Niewoehner <linux@mniewoehner.de>

> ---
> 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
> 

I?m a bit confused since git log says bd84f4ae9986 has been merged in 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has not been applied anyways ...
However, I tested you your two patches with ?magically reverted? bd84f4ae9986 (msleep 50) on rk3188.
The sdcard keeps being detected and boots just fine.

Best regards
Michael