[PATCH V2] [ARM] Add ARCH_PROVIDES_UDELAY config option

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, May 21, 2010 at 03:01:48PM -0700, Saravana Kannan wrote:
> Russell King - ARM Linux wrote:
>> We may be running into the same problem which we did with the printk
>> clock - that is using a machine provided sched_clock() or clocksource
>> requires MMIO accesses, which can only be done after the IO mappings
>> have been initialized.
>>
>> Let's hope no one ever uses udelay() before the necessary IO mappings
>> are present.
>
> Is the patch that uses CONFIG_ARCH_PROVIDES_UDELAY acceptable? I don't  
> care much for how each arch decides to implement it, but I think we  
> should have this config to let each arch decide how they want to handle  
> udelay.
>
> I personally prefer not to use the sched clock source due to the  
> unnecessary complexities. If you have a some kind of constant counter,  
> it sounds much simpler to just use it instead of adding dependencies  
> between udelay and sched clock.

My point is not specific to sched_clock, but to counters which on ARM
are 99.9% always memory mapped, and therefore inaccessible during the
very early kernel boot.  sched_clock was merely an illustration of the
problem.