[PATCH v2 2/2] ARM: delay: allow timer-based delay implementation to be selected

[shinya.kuribayashi.px@renesas.com (Shinya Kuribayashi)]

On 7/13/2012 1:40 AM, Stephen Boyd wrote:
>>>> As a result, actual udelay()s may be toooo long than expected, in
>>>> particular udelay()s used between init_current_timer_delay() and
>>>> calibrate_delay().  It's unlikely be short, as the frequency of a
>>>> counter for read_current_timer is typically slower than CPU frequency.
>>> Surely using udelay before calibrate_delay_loop has been called is a
>>> fundamental error?
>> Got it.  I'm just not confident about disallowing early use of udelay().
>>
> 
> I don't think it's an error. Instead you get a very large delay, similar
> to what would happen if you called udelay() before calibrate_delay()
> anyway (see the comment in init/main.c above loops_per_jiffy).

Thanks, so I'd set up loops_per_jiffy early, along with lpj_fine in
init_current_timer_delay().

As a matter of fact, I do have early use of udelay()s in my tree :-)
Will give it a try for some time.
-- 
Shinya Kuribayashi
Renesas Electronics