Date: Sat, 19 Mar 2016 00:14:49 +0100 (CET)
From: Stefan Wahren <stefan.wahren@i2se.com>
To: John Youn <John.Youn@synopsys.com>, Doug Anderson <dianders@chromium.org>,
        Eric Anholt <eric@anholt.net>, Martin Sperl <kernel@martin.sperl.org>
Cc: Michael Niewoehner <linux@mniewoehner.de>,
        Tao Huang <huangtao@rock-chips.com>,
        Julius Werner <jwerner@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        Caesar Wang <caesar.upstream@gmail.com>,
        Heiko Stuebner <heiko@sntech.de>, Felipe Balbi <balbi@kernel.org>,
        Remi Pommarel <repk@triplefau.lt>
Message-ID: <1440674775.86542.7bdab192-0ed1-49f2-8559-819af7131cbd.open-xchange@email.1und1.de>
In-Reply-To: <56E9A5E8.7090102@synopsys.com>
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>
 <CAD=FV=VygPvq+XxEwVCX8hofOGSsXGdPU6tKw6GPcQAkx8GZtA@mail.gmail.com>
 <941828343.8833.cdbd40c7-e6f4-4b3e-9665-30fc6680f6e0.open-xchange@email.1und1.de>
 <CAD=FV=U5tgynrXubjnnzusYf84mEwqZ_C16gAMpc6KHZoiNhZA@mail.gmail.com>
 <56E1C79D.3090104@synopsys.com> <56E9A5E8.7090102@synopsys.com>
Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on
 bcm2835"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Importance: Medium
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3422
Lines: 106

Hi Eric,
hi Martin,

> John Youn <John.Youn@synopsys.com> hat am 16. März 2016 um 19:28 geschrieben:
>
>
> 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 <stefan.wahren@i2se.com>
> >> wrote:
> >>>
> >>>> Doug Anderson <dianders@chromium.org> hat am 7. März 2016 um 22:30
> >>>> geschrieben:
> >>>>
> >>>>
> >>>> Stefan,
> >>>>
> >>>> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren <stefan.wahren@i2se.com>
> >>>> wrote:
> >>>>> Hi Doug,
> >>>>>
> >>>>>> Douglas Anderson <dianders@chromium.org> hat am 4. März 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 applying
> >>>>> 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 forced to
> >>> host
> >>> [ 2.153965] dwc2 20980000.usb: Waited 49996 us, 0x00201000 => 0x01001000,
> >>> 0x00000000 => 0x02002000
> >>> [ 2.174930] dwc2 20980000.usb: Forcing mode to host
> >>>
> >>> So i changed the delay in patch #1 to msleep(50) and then both patches
> >>> 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?
>
> 2. Also is the PHY clock stopped during the reset or is the PHY PLL
> lock times high in the order of ms?
>
> 3. In these cases, is the PHY actually an FS Transceiver and not a
> UTMI/ULPI PHY?

are you able to answer these questions 1 - 3 for BCM2835? I don't want to say
something wrong here.

>
> 4. Which version of the controller is being used in these cases?

@John: The BCM2835 has version 2.80a

Regards
Stefan

>
> Regards,
> John