On Wed, Jan 18, 2012 at 19:41:47, Russell King - ARM Linux wrote: > On Wed, Jan 18, 2012 at 01:34:55PM +0000, Hiremath, Vaibhav wrote: > > On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: > > > On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: > > > > Convert counter_32k clocksource driver to standard platform_driver > > > > and move it drivers/clocksource/ directory. > > > > > > > > Also, rename it to more generic name "omap-32k.c". > > > > > > NAK. sched_clock is supposed to be available early. Platform device > > > driver initialization is FAR too late. > > > > > Russell, > > > > Sched_clock is available very early during boot sequence. Initially gp-timer > > (dmtimer) will get registered as a clocksource. Please refer to the file > > mach-omap2/timer.c > > > > 32k_sync timer (omap-32k.c) will come get registered during arch_init. > > > > Just FYI, the way I tested it is, I used kernel parameter > > "clocksourse=counter-32k", the switch from gp-timer to 32k timer > > will happen once it gets registered. > > So please delete the sched_clock code from the 32k timer stuff you've > moved to a platform driver. It will cause sched_clock to reset to zero, > and that's bad news. > Oops...you are right, yes it may get reset to zero. Missed this point. > Only one sched_clock() should ever be registered, and that should only be > registered very early at boot time. > I think this whole platform_driver approach will not work here, I have to cleanup existing plat-omap/counter-32k.c code only and add hwmod (eventually DT) support in it. I was also not fully convinced with this approach, just followed legacy code here; and that was the reason I have submitted patch-series as a RFC to initiate discussion and get some community opinion. Thanks Russell... Thanks, Vaibhav -- 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
