Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932094AbcCSJq3 (ORCPT ); Sat, 19 Mar 2016 05:46:29 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:54018 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbcCSJqS convert rfc822-to-8bit (ORCPT ); Sat, 19 Mar 2016 05:46:18 -0400 Date: Sat, 19 Mar 2016 10:45:50 +0100 (CET) From: Stefan Wahren To: John Youn , Martin Sperl , Eric Anholt , Doug Anderson Cc: Michael Niewoehner , Tao Huang , Julius Werner , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , Caesar Wang , Heiko Stuebner , Felipe Balbi , Remi Pommarel Message-ID: <871892038.89321.35996342-72cd-48a5-8893-944da9f8a599.open-xchange@email.1und1.de> In-Reply-To: <87fuvn1a9p.fsf@eliezer.anholt.net> References: <1457115786-11370-1-git-send-email-dianders@chromium.org> <1457115786-11370-2-git-send-email-dianders@chromium.org> <1400647253.149212.b3bb45b6-c852-4cf1-9d3e-9fb299176369.open-xchange@email.1und1.de> <941828343.8833.cdbd40c7-e6f4-4b3e-9665-30fc6680f6e0.open-xchange@email.1und1.de> <56E1C79D.3090104@synopsys.com> <56E9A5E8.7090102@synopsys.com> <1440674775.86542.7bdab192-0ed1-49f2-8559-819af7131cbd.open-xchange@email.1und1.de> <87fuvn1a9p.fsf@eliezer.anholt.net> Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.0-Rev26 X-Originating-Client: com.openexchange.ox.gui.dhtml X-Provags-ID: V03:K0:IVhvgZZIjKXD+hD9eTWqaU6RLQnKutBJGFlF6ngqzxPgVKr1v+t KjquIJWz3k01l9qeze6pf92xMU/fmsJ5ZM3qSebNgH0y+xmEXgXMiyXOYNRly0WLb5qtlHZ 5B1rOuk/M6n4saRmJ1k5zeHxOzmc5X3kKInnwkLcchEKJRO4y+8j+Zr6+ce4drV+0I5KbPR H6nRnCenEt5+ur99QVEtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:3+sodjjNIug=:qwJ6XjwinlDXOF04VthzzG 9981FFXIpMDzgnZrWNxXaKQXsUIb9GgExuHCmRP5RxAQTZ40oyEDk+ldizeWnSDTqYpkFaERt xnudkcuplD2lDgChpkv0vGS+s5RiVCsrafOXtTg/5hOmeIvYrAvzE6G+NntvkqcanSdKONfGr 361EMft5RrVH1JmKFRvuqlxHByh3r2ZlnhgRkizIFl01CivYFcr0gmwWGwFJL1hI64FXcjraO dRBhEa0HLseggmDdLO8FkbhPPLVrZSGu0lGyC5Byp/YjBbwzKZf/JJrfZY9O773xEh8uHkIXl 0R9DOpWjgG5Bd5hkafH/0P570HLbz/GXwss+qtRedyAgezYiOqJG5EO0dbUUa9q/izHMDtwXI QcxvG7a9tUZxCJOlQMxScEjmbFl9AtNqFfx6Y14RgtKmPBkNKiUabr8DEuTqwFu1l2J9IKC+I A0KZm2QzpO8Fy6YzuYzR220xSwRWToqeEYCKkLw8k5T6KK1LbmbZqwLyGKl5aoi1yKCmMI03l N/QuIoOxmqWFTV7OC1L20mat/EhJjl9sk6v1Cn/0LXByZ5BXW4KADdVKT7Wnh8qfgc+ki/yXa hd1PU/5B6d25q9jT+m1Xe6EEnvcAuxp3y66bl+ZpicuOyZXHnCti3LdBCI7B//OJlDlPgKjRo mYBv3FZGaw7tEtqqVwm3UWc6uk8GU2GfSKE2sRvWDPOhubyPDsTVL+Rqp368QXpBYT8q+KseS tUbuUiLKavUmmBv/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5012 Lines: 143 Hi, > Eric Anholt hat am 19. März 2016 um 03:17 geschrieben: > > > Stefan Wahren writes: > > > Hi Eric, > > hi Martin, > > > >> John Youn 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 > >> >> wrote: > >> >>> > >> >>>> Doug Anderson hat am 7. März 2016 um 22:30 > >> >>>> geschrieben: > >> >>>> > >> >>>> > >> >>>> Stefan, > >> >>>> > >> >>>> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren > >> >>>> > >> >>>> wrote: > >> >>>>> Hi Doug, > >> >>>>> > >> >>>>>> Douglas Anderson 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.