[PATCH v2 2/2] ARM: delay: allow timer-based delay implementation to be selected
Shinya Kuribayashi
shinya.kuribayashi.px at renesas.com
Thu Jul 12 05:35:37 EDT 2012
On 7/12/2012 5:44 PM, Will Deacon wrote:
>> On 6/30/2012 2:33 AM, Will Deacon wrote:
>>> +void __init init_current_timer_delay(unsigned long freq)
>>> +{
>>> + pr_info("Switching to timer-based delay loop\n");
>>> + lpj_fine = freq / HZ;
>>> + arm_delay_ops.delay = __timer_delay;
>>> + arm_delay_ops.const_udelay = __timer_const_udelay;
>>> + arm_delay_ops.udelay = __timer_udelay;
>>> +}
>>
>> Once this function is processed, the udelay() behavior changes
>> _immediately_ from loop-based delay to timer-based one, without waiting
>> for 'loops_per_jiffy' itself being corrected in calibrate_delay().
>>
>> 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().
Shinya
More information about the linux-arm-kernel
mailing list