[PATCH V2] [ARM] Add ARCH_PROVIDES_UDELAY config option
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri May 21 18:06:53 EDT 2010
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.
More information about the linux-arm-kernel
mailing list