Hi,
> Eric Anholt <eric@xxxxxxxxxx> hat am 19. März 2016 um 03:17 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@xxxxxxxx> writes:
>
> > Hi Eric,
> > hi Martin,
> >
> >> John Youn <John.Youn@xxxxxxxxxxxx> 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@xxxxxxxx>
> >> >> wrote:
> >> >>>
> >> >>>> Doug Anderson <dianders@xxxxxxxxxxxx> hat am 7. März 2016 um 22:30
> >> >>>> geschrieben:
> >> >>>>
> >> >>>>
> >> >>>> Stefan,
> >> >>>>
> >> >>>> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren
> >> >>>> <stefan.wahren@xxxxxxxx>
> >> >>>> wrote:
> >> >>>>> Hi Doug,
> >> >>>>>
> >> >>>>>> Douglas Anderson <dianders@xxxxxxxxxxxx> 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.
please correct me if i am wrong, but according to the datasheet [1] there should
be 2 PHYs:
Feature/Parameter | Selected value
High-Speed PHY Interfaces | 1: UTMI+
USB 1.1 Full-Speed Serial Transceiver Interface | 1: Dedicated FS
But non of them is in the BCM2835 devicetree and i don't know if there is any
PHY driver
we could use. Also there is no OTG clock decribed for dwc2.
Btw the USB_GAHBCFG register is modified for BCM2835 following p. 204 in the
datasheet. I don't know
if it's important for this issue.
[1] -
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
Thanks
Stefan
>
> >> 4. Which version of the controller is being used in these cases?
> >
> > @John: The BCM2835 has version 2.80a
>
> Yeah, that looks right.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
