From patchwork Wed Sep 14 14:05:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Heiko Stuebner X-Patchwork-Id: 9331579 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2407F6077A for ; Wed, 14 Sep 2016 14:05:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 14D5D29A16 for ; Wed, 14 Sep 2016 14:05:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 099502A078; Wed, 14 Sep 2016 14:05:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6A2B429A16 for ; Wed, 14 Sep 2016 14:05:50 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bkAot-0006Ar-Du; Wed, 14 Sep 2016 14:05:47 +0000 Received: from gloria.sntech.de ([95.129.55.99]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bkAon-0005SQ-05; Wed, 14 Sep 2016 14:05:46 +0000 Received: from ip9234aa3a.dynamic.kabel-deutschland.de ([146.52.170.58] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bkAoO-0006Mv-QK; Wed, 14 Sep 2016 16:05:16 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: John Youn Subject: Re: [PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays Date: Wed, 14 Sep 2016 16:05:15 +0200 Message-ID: <6145714.tWcMvDakYx@diego> User-Agent: KMail/4.14.10 (Linux/4.6.0-1-amd64; KDE/4.14.22; x86_64; ; ) In-Reply-To: <97a3539d-7176-086f-71f9-371d8d4b016c@synopsys.com> References: <2928813.DT7ys6u6xZ@diego> <97a3539d-7176-086f-71f9-371d8d4b016c@synopsys.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160914_070541_339586_D64FAFC3 X-CRM114-Status: GOOD ( 17.26 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stefan Wahren , "linux-rockchip@lists.infradead.org" , "linux-rpi-kernel@lists.infradead.org" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Am Dienstag, 13. September 2016, 12:04:12 schrieb John Youn: > On 9/13/2016 11:39 AM, Heiko Stübner wrote: > > Am Dienstag, 13. September 2016, 20:07:25 schrieb Stefan Wahren: > >> Hi Heiko, > >> > >>> Heiko Stuebner hat am 12. September 2016 um 13:05 > >>> geschrieben: > >>> > >>> > >>> Hi Stefan, > >>> > >>> Am Montag, 12. September 2016, 07:20:44 CEST schrieb Stefan Wahren: > >>>>> Heiko Stuebner hat am 11. September 2016 um 23:19 > >>>>> geschrieben: > >>>>> > >>>>> Am Mittwoch, 7. September 2016, 19:39:43 CEST schrieb John Youn: > >>>>>> When a force mode bit is set and the IDDIG debounce filter is > >>>>>> enabled, > >>>>>> there is a delay for the forced mode to take effect. This delay is > >>>>>> due > >>>>>> to the IDDIG debounce filter and is variable depending on the > >>>>>> platform's > >>>>>> PHY clock speed. To account for this delay we can poll for the > >>>>>> expected > >>>>>> mode. > >>>>>> > >>>>>> On a clear force mode, since we don't know what mode to poll for, > >>>>>> delay > >>>>>> for a fixed 100 ms. This is the maximum delay based on the slowest > >>>>>> PHY > >>>>>> clock speed. > >>>>>> > >>>>>> Tested-by: Stefan Wahren > >>>>>> Signed-off-by: John Youn > >>>>>> --- > >>>>> > >>>>> [...] > >>>>> > >>>>>> @@ -475,12 +478,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg > >>>>>> *hsotg) > >>>>>> > >>>>>> __func__, hsotg->dr_mode); > >>>>>> > >>>>>> break; > >>>>>> > >>>>>> } > >>>>>> > >>>>>> - > >>>>>> - /* > >>>>>> - * NOTE: This is required for some rockchip soc based > >>>>>> - * platforms. > >>>>>> - */ > >>>>>> - msleep(50); > >>>>>> > >>>>>> } > >>>>> > >>>>> sorry for not finding the time to test your subsequent versions, but > >>>>> this > >>>>> still > >>>>> acts up on my Rockchip boards, as I'm still running into errors like > >>>>> > >>>>> [ 4.875570] usb usb2-port1: connect-debounce failed > >>>> > >>>> could you please name the relevant DTS file of the affected boards? > >>> > >>> So far I've been able to see that on > >>> > >>> rk3188-radxarock > >>> rk3036-kylin > >>> > >>> both on host-only dwc2 controllers. > >> > >> thanks, does patch 1 & 2 already have a negative effect on these > >> controllers? > > > > nope, patches 1+2 alone are ok and only the msleep(50) going away causes > > problems. I'm back home now, so I'll hopefully have time to check > > host-only > > vs. otg dwc2 controllers tomorrow as well. > > Ok, thanks for testing Heiko. > > Given that, let's try to fix this in the next -rc (or before) because > I think the Raspberry Pi needs the other parts of that last patch. We > can just revert the msleep(50) if needed. I could nicely confirm, that only the host-only controller seems affected by this. Same kernel image that fails on the host-only one with the "connect- debounce failed" message seems to work once I switch that over to the otg controller and the system comes up nicely again. So if we don't find the root cause in the short term, maybe we could at least limit the delay for host-only variants, like ---------------------- 8< ------------------- ---------------------- 8< ------------------- I've been running with that change for some time now on both the rk3036-kylin and rk3188-radxarock. Plugged and unplugged different combinations of usb-devices on the usb otg and host ports, so far seems to work. Heiko diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index fa9b26b..4c0fa0b 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -463,9 +463,18 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg) */ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg) { + bool ret; + switch (hsotg->dr_mode) { case USB_DR_MODE_HOST: - dwc2_force_mode(hsotg, true); + ret = dwc2_force_mode(hsotg, true); + /* + * NOTE: This is required for some rockchip soc based + * platforms on their host-only dwc2. + */ + if (!ret) + msleep(50); + break; case USB_DR_MODE_PERIPHERAL: dwc2_force_mode(hsotg, false);