[PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Hiremath, Vaibhav]

On Sat, Apr 07, 2012 at 02:48:47, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav at ti.com> 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