There is one issue which remains with this code - that is the initialization ordering. init/main.c: setup_arch(&command_line); ... sched_init(); ... early_irq_init(); init_IRQ(); ... timekeeping_init(); time_init(); sched_init() calls init_idle() which calls sched_clock() to set the start time for the idle thread. However, our sched_clock() is not initialized (in general) until init/main.c calls time_init(). This results in a big step in the sched_clock() return value during boot, which is probably not desirable. At the moment, I work around this by explicitly setting the epoch_ns to zero after the first update callback - but this means that sched_clock() will only start at this point, which may not be desirable for everyone. Some sched_clock() implementations rely upon clocksource code (they use the clocksource read function) and this is only initialized when the clocksource is registered. There's also the matter of the clock rate. It's probably not a good idea to register clocksources before timekeeping_init() has happened either. I can provide an init_early() method in the machine description which setup_arch() can call as the last thing it does - this will happen after the ->reserve and ->map_io callbacks, but before interrupts and timers have been setup. This is the ideal time to setup the sched_clock(). However, that means digging through lots of arch code to sort out what can be moved where, and that's going to be inherently unreliable. I think init_early() has merit in other ways - it'll allow us to remove crap from the ->map_io callbacks which is doing stuff like registering clk structures and so forth. Any other suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
