Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754614AbcCSCRy (ORCPT ); Fri, 18 Mar 2016 22:17:54 -0400 Received: from anholt.net ([50.246.234.109]:40881 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753795AbcCSCRo (ORCPT ); Fri, 18 Mar 2016 22:17:44 -0400 From: Eric Anholt To: Stefan Wahren , John Youn , Doug Anderson , Martin Sperl Cc: Michael Niewoehner , Tao Huang , Julius Werner , Greg Kroah-Hartman , "linux-kernel\@vger.kernel.org" , "linux-usb\@vger.kernel.org" , Caesar Wang , Heiko Stuebner , Felipe Balbi , Remi Pommarel Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" In-Reply-To: <1440674775.86542.7bdab192-0ed1-49f2-8559-819af7131cbd.open-xchange@email.1und1.de> References: <1457115786-11370-1-git-send-email-dianders@chromium.org> <1457115786-11370-2-git-send-email-dianders@chromium.org> <1400647253.149212.b3bb45b6-c852-4cf1-9d3e-9fb299176369.open-xchange@email.1und1.de> <941828343.8833.cdbd40c7-e6f4-4b3e-9665-30fc6680f6e0.open-xchange@email.1und1.de> <56E1C79D.3090104@synopsys.com> <56E9A5E8.7090102@synopsys.com> <1440674775.86542.7bdab192-0ed1-49f2-8559-819af7131cbd.open-xchange@email.1und1.de> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 18 Mar 2016 19:17:38 -0700 Message-ID: <87fuvn1a9p.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5005 Lines: 145 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Wahren writes: > Hi Eric, > hi Martin, > >> John Youn hat am 16. M=C3=A4rz 2016 um 19:28 ge= schrieben: >> >> >> On 3/10/2016 11:14 AM, John Youn wrote: >> > On 3/9/2016 11:06 AM, Doug Anderson wrote: >> >> Stefan, >> >> >> >> On Wed, Mar 9, 2016 at 11:01 AM, Stefan Wahren >> >> wrote: >> >>> >> >>>> Doug Anderson hat am 7. M=C3=A4rz 2016 um 2= 2:30 >> >>>> geschrieben: >> >>>> >> >>>> >> >>>> Stefan, >> >>>> >> >>>> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren >> >>>> wrote: >> >>>>> Hi Doug, >> >>>>> >> >>>>>> Douglas Anderson hat am 4. M=C3=A4rz 2016= um 19:23 >> >>>>>> geschrieben: >> >>>>>> >> >>>>>> >> >>>>>> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on >> >>>>>> bcm2835") now that we've found the root cause. See the change >> >>>>>> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"). >> >>>>> >> >>>>> adding a delay of 10 ms after a core reset might be a idea, but ap= plying >> >>>>> both >> >>>>> patches breaks USB support on RPi :-( >> >>>>> >> >>>>> I'm getting the wrong register values ... >> >>>> >> >>>> Ugh. :( >> >>>> >> >>>> Just out of curiosity, if you loop and time long it takes for the >> >>>> registers to get to the right state after reset, what do you get? >> >>>> AKA, pick: >> >>>> >> >>>> https://chromium-review.googlesource.com/331260 >> >>>> >> >>>> ...and let me know what it prints out. >> >>> >> >>> On my Raspberry Pi B i get the following: >> >>> >> >>> [ 2.084411] dwc2 20980000.usb: mapped PA 20980000 to VA cc880000 >> >>> [ 2.084461] dwc2 20980000.usb: cannot get otg clock >> >>> [ 2.084549] dwc2 20980000.usb: registering common handler for irq33 >> >>> [ 2.084713] dwc2 20980000.usb: Configuration mismatch. dr_mode force= d to >> >>> host >> >>> [ 2.153965] dwc2 20980000.usb: Waited 49996 us, 0x00201000 =3D> 0x01= 001000, >> >>> 0x00000000 =3D> 0x02002000 >> >>> [ 2.174930] dwc2 20980000.usb: Forcing mode to host >> >>> >> >>> So i changed the delay in patch #1 to msleep(50) and then both patch= es >> >>> work like >> >>> a charm. >> >> >> >> Great news! :-) >> >> >> >> John: it's pretty clear that there's something taking almost exactly >> >> 10ms on my system and almost exactly 50ms on Stefan's system. Is >> >> there some register we could poll to see when this process is done? >> >> ...or can we look at the dwc2 revision number / feature register and >> >> detect how long to delay? >> >> >> > >> > Hi Doug, >> > >> > I'll have to ask around to see if anyone knows about this. And I'll >> > run some tests on the platforms I have available to me as well. >> > >> >> There's still nothing definitive on our end as to why this is >> happening. Also I don't think there is any other way to poll the >> reset. Our hardware engineers asked for some more information to look >> into it further. Doug, Stefan, Caesar, and anyone else with a related >> platform, do you know the answers to the following: >> >> 1. What is the AHB Clock frequency? Is the AHB Clock gated during >> Reset? Low confidence here as I'm tracing lines across a ton of modules, but it looks like it comes from the USB AXI clock in peri_image, which is a gate on the normal 250Mhz APB clock, but nothing should be touching that gate register as part of USB reset as far as I know. >> 2. Also is the PHY clock stopped during the reset or is the PHY PLL >> lock times high in the order of ms? PHY PLL lock times should be about 40 us, and reset needs to be high for 40us. I haven't traced where GRSTCTL_CSFTRST (the reset I assume you're talking about here) goes, so I can't say if it's an input to PHY reset. >> 3. In these cases, is the PHY actually an FS Transceiver and not a >> UTMI/ULPI PHY? The PHY docs say it's UTMI+ compatible. >> 4. Which version of the controller is being used in these cases? > > @John: The BCM2835 has version 2.80a Yeah, that looks right. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJW7LbDAAoJELXWKTbR/J7oAg0P/0GB5B+Kp2XeaK7GY9ytNWuH mxYWGDgbZxpy8dHVBWB0UaXVz4r0KUY0ymYbQivCZxm2hFGP9uL7t/s+SRst4A4u PW6yV+SOJG4RjKYZHpSB2UT5LyInqC3skrPfZ8WDLsA6X/u45+NYUfKsR/hvHUOI /XstKIn1CnwJ8Vo4YHkhvG24hebSppSCVvjIBARF8kl1Sro+boZWdY7oHZY7RGb8 u0sSYzKb2HAsXht66OryvYn6Fu4JsXCXr19haHTKlOg9mUieQxM6sh/CxP3MjHJz hiwJd+/ZOORgAAPQy0Nz4PgpaM72nWllB6pTXUjqTjCZkRdkOhHNJNIzaEm9wAHq TxkwlhPqwBJI+Cv8cJudONPdhwo6BByolPD7TXiGxGKofDIMYa2A9Znv/Dt/tO7U erPuGozUXzAAbPNnaZtS3xkulH46gQulUtWEt4UQdbPYzT6c0turuBVCEH//xV1E +96huz9epEXcy3NqKKuHNIOZCEUG2zoHJv195cHrM+5bDCJDltp8cfEKmCoz9N3q xwwtF9dELJYsf4QgidltqCWr1RPNLguHnEJpS2B3jZuCDQ28Qnp+axrsNoXEeki/ fcIG7ZFQqhPE4o9RdeRCZkBClFrYqMR3iOe74gj/4RhNSo3b3Du4EM4QCnTGwkzk Al+6k3VZOUxVDtb5J+L5 =3LqK -----END PGP SIGNATURE----- --=-=-=--