Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1360996 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-19 00:20 +0100
    Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Eric Anholt <eric@anholt.net> - 2016-03-19 03:20 +0100
      Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Martin Sperl <kernel@martin.sperl.org> - 2016-03-19 08:50 +0100
        Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-19 11:00 +0100
          Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Martin Sperl <kernel@martin.sperl.org> - 2016-03-19 11:20 +0100
            Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-19 13:20 +0100
      Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-19 10:50 +0100

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

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

[toc] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

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

> On 19.03.2016, at 03:17, Eric Anholt <eric@anholt.net> wrote:
> 
> 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:
>>>>> 
>>>>> 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?
>>>>> 

Maybe this difference is related to overclocking settings in the firmware?

>>> 
>>> 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.
> 
Isn’t it possible that this clock (probably BCM2835_CLOCK_VPU) is 
changed by the firmware due to overclocking settings in /boot/config.txt?

Martin

[toc] | [prev] | [next] | [standalone]

#1361072

Hi,

> Martin Sperl <kernel@martin.sperl.org> hat am 19. März 2016 um 08:44
> geschrieben:
>
>
>
> > On 19.03.2016, at 03:17, Eric Anholt <eric@anholt.net> wrote:
> >
> > 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:
> >>>>>
> >>>>> 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?
> >>>>>
>
> Maybe this difference is related to overclocking settings in the firmware?
>
> >>>
> >>> 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.
> >
> Isn’t it possible that this clock (probably BCM2835_CLOCK_VPU) is
> changed by the firmware due to overclocking settings in /boot/config.txt?

i don't use any overclocking settings. 

Are you able to reproduce the behavior on your Pi?

Stefan

>
> Martin
>
>

[toc] | [prev] | [next] | [standalone]

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

> On 19.03.2016, at 10:52, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> 
> Hi,
> 
>> Martin Sperl <kernel@martin.sperl.org> hat am 19. März 2016 um 08:44
>> geschrieben:
>> 
>> 
>> 
>>> On 19.03.2016, at 03:17, Eric Anholt <eric@anholt.net> wrote:
>>> 
>>> 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:
>>>>>>> 
>>>>>>> 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?
>>>>>>> 
>> 
>> Maybe this difference is related to overclocking settings in the firmware?
>> 
>>>>> 
>>>>> 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.
>>> 
>> Isn’t it possible that this clock (probably BCM2835_CLOCK_VPU) is
>> changed by the firmware due to overclocking settings in /boot/config.txt?
> 
> i don't use any overclocking settings. 
> 
> Are you able to reproduce the behavior on your Pi?

I did not have any problems with USB recently (using 4.5), 
so I would not have any idea how to reproduce it.

Note that I am using it with an AXIS USB-ethernet dongle plus USB-stick
all the time on my Compute Module connected via a tiny hub, 
so I wonder if that qualifies as being able to trigger the issue...

Martin

[toc] | [prev] | [next] | [standalone]

#1361095

Hi,

> Martin Sperl <kernel@martin.sperl.org> hat am 19. März 2016 um 11:10
> geschrieben:
>
>
> > On 19.03.2016, at 10:52, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> >
> > Hi,
> >
> >> Martin Sperl <kernel@martin.sperl.org> hat am 19. März 2016 um 08:44
> >> geschrieben:
> >>
> >>
> >>
> >>> On 19.03.2016, at 03:17, Eric Anholt <eric@anholt.net> wrote:
> >>>
> >>> 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:
> >>>>>>>
> >>>>>>> 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?
> >>>>>>>
> >>
> >> Maybe this difference is related to overclocking settings in the firmware?
> >>
> >>>>>
> >>>>> 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.
> >>>
> >> Isn’t it possible that this clock (probably BCM2835_CLOCK_VPU) is
> >> changed by the firmware due to overclocking settings in /boot/config.txt?
> >
> > i don't use any overclocking settings.
> >
> > Are you able to reproduce the behavior on your Pi?
>
> I did not have any problems with USB recently (using 4.5),
> so I would not have any idea how to reproduce it.
>
> Note that I am using it with an AXIS USB-ethernet dongle plus USB-stick
> all the time on my Compute Module connected via a tiny hub,
> so I wonder if that qualifies as being able to trigger the issue...

the probe problem appears after applying John's patch series (it's not in 4.5):

[RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
[RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

Please follow the complete discussion here [1].

[1] - http://marc.info/?l=linux-kernel&m=145711582915801&w=2

>
> Martin

[toc] | [prev] | [next] | [standalone]

#1361071

Hi,

> Eric Anholt <eric@anholt.net> hat am 19. März 2016 um 03:17 geschrieben:
>
>
> 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.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web