On Sat, Apr 07, 2012 at 02:48:47, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes:
>
> [...]
>
> > I liked Santosh's idea in using command line argument "clocksource=" and
> > make decision based on this. I have implemented it and tried it on both
> > OMAP3EVM and beaglebone and it works great.
> >
> > I have introduced something like this in mach-omap2/timer.c,
> >
> > static int __init omap2_override_clocksource(char* str)
> > {
> > if (!str)
> > return 0;
> > /*
> > * For OMAP architecture, we only have two options
> > * - sync_32k (default)
> > * - gp timer
> > */
> > if (!strcmp(str, "gp timer"))
> > use_gptimer_clksrc = true;
> >
> > return 0;
> > }
> > early_param("clocksource", omap2_override_clocksource);
>
> How does this interact with the existing clocksource cmdline parameter
> already in kernel/time/clocksource.c? (c.f. boot_override_clocksource())
>
Not really, it doesn't interact with existing clocksource parameter
Already present in kernel/time/clocksource.c.
Both works independently...
> IMO, this duplicates that functionality but less elegantly.
>
> What should happen is to let clocksource selection happen normally
> (based on presence or lack of HW, or cmdline override.) Once that has
> happened, you can then setup_sched_clock() with parameters from querying
> the clocksource itself.
>
After Russell's response, it is clear that we should not change the
clocksource dynamically, its not useful. So I do not see any benefits
following that feature (as of now).
We just need to make sure that, we detect our clocksource and call
setup_sched_clock() with appropriate rating.
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
