[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=VygPvq+XxEwVCX8hofOGSsXGdPU6tKw6GPcQAkx8GZtA@mail.gmail.com>
Date: Mon, 7 Mar 2016 13:30:23 -0800
From: Doug Anderson <dianders@...omium.org>
To: Stefan Wahren <stefan.wahren@...e.com>
Cc: John Youn <johnyoun@...opsys.com>,
Heiko Stuebner <heiko@...ech.de>,
Felipe Balbi <balbi@...nel.org>,
Michael Niewoehner <linux@...ewoehner.de>,
Tao Huang <huangtao@...k-chips.com>,
Julius Werner <jwerner@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
Caesar Wang <caesar.upstream@...il.com>,
Remi Pommarel <repk@...plefau.lt>
Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"
Stefan,
On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren <stefan.wahren@...e.com> wrote:
> Hi Doug,
>
>> Douglas Anderson <dianders@...omium.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
Powered by blists - more mailing lists