Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751772AbcCVUhe (ORCPT ); Tue, 22 Mar 2016 16:37:34 -0400 Received: from smtprelay2.synopsys.com ([198.182.60.111]:54536 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750696AbcCVUha (ORCPT ); Tue, 22 Mar 2016 16:37:30 -0400 Subject: Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835" To: Doug Anderson , John Youn 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> <56F19C6C.7000203@synopsys.com> CC: Stefan Wahren , 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 , Kever Yang From: John Youn Message-ID: <56F1AD06.1010301@synopsys.com> Date: Tue, 22 Mar 2016 13:37:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.9.139.139] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2734 Lines: 68 On 3/22/2016 12:44 PM, Doug Anderson wrote: > John, > > On Tue, Mar 22, 2016 at 12:26 PM, John Youn wrote: >> Thanks for the debug logs and everyones help. >> >> After reviewing with our hardware engineers, it seems this is likely >> to do with the IDDIG debounce filtering when switching between >> modes. You can see if this is enabled in your core by checking >> GHWCFG4.IddgFltr. >> >> From the databook: >> >> OTG_EN_IDDIG_FILTER >> >> Specifies whether to add a filter on the "iddig" input from the >> PHY. If your PHY already has a filter on iddig for de-bounce, then >> it is not necessary to enable the one in the DWC_otg. The filter >> is implemented in the DWC_otg_wpc module as a 20-bit counter that >> works on the PHY clock. In the case of the UTMI+ PHY, this pin is >> from the PHY. In the case of the ULPI PHY, this signal is >> generated by the ULPI Wrapper inside the core. >> >> >> This only affects OTG cores and the delay is 10ms for 30MHz PHY clock >> and 50ms with a 6MHz PHY clock. > > Wow, nice to have it so perfectly explained! :) > > >> The reason we see this after a reset is that by default the IDDIG >> indicates device mode. But if the id pin is set to host the core will >> immediately detect it after the reset and trigger the filtering delay >> before changing to host mode. >> >> This delay is also triggered by force mode. This is the origin of the >> 25 ms delay specified in the databook. The databook did not take into >> account that there might be a 6MHz clock so this delay could actually >> be up to 50 ms. So we aren't delaying enough time for those cases. >> >> I think this explains all the problems and platform differences we are >> seeing related to this. >> >> I think we can just add an IDDIG delay after a force mode, a clear >> force mode, and any time after reset where we don't do either a force >> or clear force mode immediately afterwards. Maybe set the delay time >> via a core parameter or measure it once on probe. Or we can probably >> just poll for the mode change in all of the above conditions. > > The driver seems to be able to figure out the PHY clock in most cases > in dwc2_calc_frame_interval(). It doesn't seem to handle 6MHz there, > though. I wonder if that's another bug? > > Polling seems fine too, though. > > >> Are you able to continue looking into this? If not, I can take it up. > > I'm pretty much out of time at this point and it sounds like you've > though through all of the corner cases. If you can take it up that > would be wonderful! :) I'm happy to give the patches a test, though! > :) > Ok sure. I'll try to get something testable within a few days. Regards, John