Re: [PATCH 0/13] 64-bit sched_clock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/12/16 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:

> 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.

I agree. I was contemplating a clock_init() or similar a way back
for setting up clock trees early. We would have to move clock tree
registration in front of the init_sched_clock() call in the init_early()
handler in many cases since the rate often comes from the clock
framework, but this is indeed where it belongs.

So a clear ACK for this approach.

Yours,
Linus Walleij
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux