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

Groups > linux.kernel > #1350508 > unrolled thread

[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

  [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Douglas Anderson <dianders@chromium.org> - 2016-03-04 19:30 +0100
    Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Michael Niewoehner <linux@mniewoehner.de> - 2016-03-05 00:00 +0100
    Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-07 19:50 +0100
      Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Doug Anderson <dianders@chromium.org> - 2016-03-07 22:40 +0100
        Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-08 19:00 +0100
        Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on  bcm2835" Stefan Wahren <stefan.wahren@i2se.com> - 2016-03-09 20:10 +0100
          Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" Doug Anderson <dianders@chromium.org> - 2016-03-09 20:10 +0100
            Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" John Youn <John.Youn@synopsys.com> - 2016-03-10 20:20 +0100
              Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" John Youn <John.Youn@synopsys.com> - 2016-03-16 19:30 +0100

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

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()").

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
 drivers/usb/dwc2/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 8710b2d3e770..7c4a6cf4c73a 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
 	set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
 	clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
 
+	/*
+	* If the force mode bit is already set, don't set it.
+	*/
+	if ((gusbcfg & set) && !(gusbcfg & clear))
+		return false;
+
 	gusbcfg &= ~clear;
 	gusbcfg |= set;
 	dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-- 
2.7.0.rc3.207.g0ac5344

[toc] | [next] | [standalone]

#1350663

Am 04.03.2016 um 19:23 schrieb Douglas Anderson <dianders@chromium.org>:

> 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()").
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Tested-by: Michael Niewoehner <linux@mniewoehner.de>

> ---
> drivers/usb/dwc2/core.c | 6 ++++++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 8710b2d3e770..7c4a6cf4c73a 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -353,6 +353,12 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
> 	set = host ? GUSBCFG_FORCEHOSTMODE : GUSBCFG_FORCEDEVMODE;
> 	clear = host ? GUSBCFG_FORCEDEVMODE : GUSBCFG_FORCEHOSTMODE;
> 
> +	/*
> +	* If the force mode bit is already set, don't set it.
> +	*/
> +	if ((gusbcfg & set) && !(gusbcfg & clear))
> +		return false;
> +
> 	gusbcfg &= ~clear;
> 	gusbcfg |= set;
> 	dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
> -- 
> 2.7.0.rc3.207.g0ac5344
> 

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

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

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

Stefan

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

#1351999

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 system I see:

[    1.990743] dwc2 ff540000.usb: Waited 300001 us, 0x04000400 =>
0x04000400, 0x02000800 => 0x02000800
[    2.119677] dwc2 ff580000.usb: Waited 9997 us, 0x00100400 =>
0x04000400, 0x00000000 => 0x02000800

I believe the difference in behavior is because of the two different
types of USB controllers (one is OTG and the other is host only).


-Doug

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

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

Hi Doug,

> 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 system I see:
>
> [ 1.990743] dwc2 ff540000.usb: Waited 300001 us, 0x04000400 =>
> 0x04000400, 0x02000800 => 0x02000800
> [ 2.119677] dwc2 ff580000.usb: Waited 9997 us, 0x00100400 =>
> 0x04000400, 0x00000000 => 0x02000800

sure, but this will take some time (weekend).

>
> I believe the difference in behavior is because of the two different
> types of USB controllers (one is OTG and the other is host only).
>
>
> -Doug

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

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

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

Stefan

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

#1354367

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?

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

#1355333

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.

Regards,
John

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

#1359222

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?

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

Regards,
John

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web