I am using this patch in our Tegra development tree.  So far, I
haven't come across any need for supporting udelay before iomap, but
if it is necessary, it could be handled in the per-architecture
implementation by using a busy loop with a worst-case count if a
sched_clock initialization flag is not set.

On Mon, Jun 21, 2010 at 6:14 PM, Saravana Kannan [off-list ref] wrote:

Russel,

Would appreciate your thoughts on this.

Colin,

Are you continuing to use the approach used in your patch in your
development tree? I just want to make sure we have a solution that everyone
can agree to.

Thanks,
Saravana

Saravana Kannan wrote:

quoted

Russell King - ARM Linux wrote:

quoted

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.

Do you know any code which uses udelay that early? I can't imagine any
non-driver code using udelay. If it's just drivers using udelay, then they
need IO mapping to have been completed for the device register access to
work and hence udelay won't have any problems.

-Saravana