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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
