[PATCH V2] [ARM] Add ARCH_PROVIDES_UDELAY config option

[Colin Cross]

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 <skannan at codeaurora.org> 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:
>>
>> Russell King - ARM Linux wrote:
>>>
>>> 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
>>
>
>