On Fri, May 21, 2010 at 03:01:48PM -0700, Saravana Kannan wrote:

Russell King - ARM Linux wrote:

quoted

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.