[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170285826.29240.227.camel@localhost.localdomain>
Date: Thu, 01 Feb 2007 00:23:46 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Daniel Walker <dwalker@...sta.com>
Cc: David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 14/23] clocksource: increase initcall priority
Daniel,
On Wed, 2007-01-31 at 14:47 -0800, Daniel Walker wrote:
> > So don't assume any platform doesn't use clocksource initcalls.
>
> What does your OMAP clocksource do now ? I thought one of the changes
> that you made was to have both 32k and mpu both registered ..
It is up to the clocksource driver, when the clocksource_register() call
is done. This may happen in early boot as well as after initializing
some other things first.
Johns clocksource code works with ARM which does the register call in
timer_init() as well as with some other hardware which gets initialized
late in the boot process.
clocksource_initcall is simply superfluid.
Adjusting the initcalls of a particular device to the point where it
becomes available is a seperate topic. I'm not in the way of that and I
think John's patch draft to solve the sound issue is heading into
exactly this direction.
We do not need another initcall level, especially not one which just
aliases an existing one.
The only thing we really want to control explicitely is when we actually
switch away from jiffies_clocksource. But this does not need an
artificial initcall at all.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists