Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]

Stefan Wahren <stefan.wahren@i2se.com> writes:

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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]