Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752723AbbBKLmj (ORCPT ); Wed, 11 Feb 2015 06:42:39 -0500 Received: from smtpbgsg2.qq.com ([54.254.200.128]:56417 "EHLO smtpbgsg2.qq.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751177AbbBKLmi (ORCPT ); Wed, 11 Feb 2015 06:42:38 -0500 X-QQ-mid: esmtp23t1423654913t304t24624 X-QQ-SSF: 0100000000000080F61200000000003 X-QQ-FEAT: Znbn/FatUBn2jtQN/1dQmJx4nPJCAkqoTtaB/QHU1F0hpYbkg2szHdboxetil av+FOoSaixX6koYRfY8UAJdFC9N8uxGFwUgIKgFORs5v4O5B/cCOXYdcc9p8/lP5Tny8SZ/ J0Klnp1yuEpP82t6oG+TIZQGuXExESB0TumQc/Z3h4tnc0s4hs9ogpjYhrN8ahGQpcH7ivB sAvKPEW4F4m8/3w+wORzr X-QQ-GoodBg: 0 Message-ID: <54DB3FBF.7010003@foxmail.com> Date: Wed, 11 Feb 2015 19:40:47 +0800 From: Roy User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: johnyoun@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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2085 Lines: 49 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. > >> 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. > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- -------- Roy Li @ Rockchip -- 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/