* Hiremath, Vaibhav <hvaibhav@xxxxxx> [120405 22:25]:
> On Fri, Apr 06, 2012 at 03:03:01, Hilman, Kevin wrote:
> >
> > What we need is only one-time selection at boot based on presence (or
> > not) of various timers. IOW, we still only ever need to call
> > setup_sched_clock() once based on which HW timers are available.
> >
> > Why not just delay the setup_sched_clock() until the clocksource is
> > decided?
I think that's we're already doing for omap1 as 15xx does not
have the 32 KiHz timer and the CONFIG_OMAP_32K_TIMER is no longer
conflicting with the MPU timer.
> 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);
Sure a cmdline override is nice to have for user selection.
But we should also by default do the right thing based on what the
board wants in .timer entry.
> It solves all issues what we have been trying address.
I'm a bit confused.. Can you briefly summarize again what all
issues you're having? Just want to select a different clocksource
for beaglebone? If you don't have the 32 KiHz then that can't
be selected naturally?
Regards,
Tony
--
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
