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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--------
Roy Li @ Rockchip
--
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
