Russell King - ARM Linux wrote:

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

quoted

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.

Agree with the point about the counters being memory mapped. But does 
any of the really early init code use udelay? AFAIK, udelay is mostly 
used when talking to devices at which point IO mapping needs to have 
been completed to be able to talk to the device in the first place.

Even otherwise, a given arch might not need udelay during early init 
code. So, we could still give them that option. No?

-Saravana