Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932134AbbBLDdV (ORCPT ); Wed, 11 Feb 2015 22:33:21 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:48949 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754242AbbBLDdU (ORCPT ); Wed, 11 Feb 2015 22:33:20 -0500 Message-ID: <54DC1EFD.1050306@synopsys.com> Date: Wed, 11 Feb 2015 19:33:17 -0800 From: John Youn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Roy , "John.Youn@synopsys.com" , Felipe Balbi CC: Yunzhi Li , "jwerner@chromium.org" , "gregory.herrero@intel.com" , "yousaf.kaukab@intel.com" , "r.baldyga@samsung.com" , Dinh Nguyen , Eddie Cai , Lin Huang , wulf , =?UTF-8?B?5p2o5Yev?= , Tao Huang , "walkrain@126.com" , "Douglas Anderson" , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , LKML Subject: Re: [RFC PATCH v1] usb: dwc2: reduce dwc2 driver probe time References: <1423577139-4165-1-git-send-email-lyz@rock-chips.com> <20150210144718.GB16711@saruman.tx.rr.com> <54DB3FBF.7010003@foxmail.com> In-Reply-To: <54DB3FBF.7010003@foxmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.9.139.255] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2859 Lines: 68 On 2/11/2015 3:42 AM, Roy wrote: > Hi John Youn: > > Could you please give some suggestions from your point of view, > about this probe time issue ? > > Thanks a lot. > > at 2015/2/11 2:23, Julius Werner wrote: >>> @@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg) >>> gusbcfg = readl(hsotg->regs + GUSBCFG); >>> gusbcfg &= ~GUSBCFG_FORCEHOSTMODE; >>> writel(gusbcfg, hsotg->regs + GUSBCFG); >>> - usleep_range(100000, 150000); >>> + usleep_range(25000, 50000); >> The point of usleep_range() is to coalesce multiple timer interrupts >> in idle systems for power efficiency. It's pretty pointless/harmful >> during probe anyway and there's almost never a reason to make the span >> larger than a few milliseconds. You should reduce this to something >> reasonable (e.g. usleep_range(25000, 26000) or even >> usleep_range(25000, 25000)) to save another chunk of time. Same >> applies to other delays above. Databook does say 25ms. From what I could gather this has to do with the debounce filter time on the IDDIG pin after the ForceHstMode/ForceDevMode is programmed. There is no way to poll this. I think the change is acceptable, even to lower the range as Julius suggested. >> >>> do you know what's the upper boundary for AHB clock ? How fast can it >>> be? It's not wise to change timers because "it works on my RK3288 >>> board", you need to guarantee that this won't break anybody else. >> But this code is already a loop that spins on the AHBIdle bit, right? >> It should work correctly regardless of the delay. The only question is >> whether the code could be more efficient with a longer sleep... but >> since the general recommendation is to delay for ranges less than >> 10us, and the AHB clock would need to be lower than 100KHz (the ones I >> see are usually in the range of tens or hundreds of MHz) to take >> longer than that, this seems reasonable to me. Agree with this. It shouldn't take nearly that long and you are polling anyways. As for the other change: > It seems that usleep_range() at boot time will pick the longest > value in the range. In dwc2_core_reset() there is a very long > delay takes 200ms, and this function run twice when probe, could > any one tell me is this delay time resonable ? I'm not sure about this value or the reasoning/history behind it. It is not in our internal code. It looks like it is taking into account the delay for the ForceHstMode/ForceDevMode programming. However, I think your change is conservative and should be ok. Maybe Samsung engineers know about this? John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/