omap clocksource timer selection: dmtimer OR 32K-Sync timer
Hiremath, Vaibhav
hvaibhav at ti.com
Fri Jan 13 08:42:36 EST 2012
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
> > Hi,
> >
> > In case of AM33xx family of devices, we do not have 32K Sync timer
> > (32K Counter) available; and the current implementation is based on
> > compile-time option, where clock-source is chosen by something like,
> >
> > File - arch/arm/mach-omap2/timer.c
> >
> > #ifdef CONFIG_OMAP_32K_TIMER
> > static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
> > {
> > ...
> > }
> > #else
> > static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
> > {
> > ...
> > }
> > #endif
> >
> >
> > But in order to support multi-omap build, we must
> > make run-time decision to use the timer for kernel clock-source, either of -
> >
> > - DMTIMER
> > - 32K Sync Timer
> >
> > The DMTIMER is already migrated to the HWMOD framework, but 32K Timer code
> > has not yet migrated to it. So the question here is,
> >
> > 1) Does it make sense to migrate counter_32k.c to search entry in hwmod
> > table and if 32k_sync timer is available in hwmod table then use 32K
> > timer for Kernel clock-source
> > OR
> > Fall back to DMTIMER.
> >
> > OMAP4 hwmod table already has entry,
> >
> > static struct omap_hwmod omap44xx_counter_32k_hwmod = {
> > .name = "counter_32k",
> > ...
> > };
> >
> > We need to have similar entries in all devices where 32K timer is present.
> >
> > 2) OR simply add another cpu_is_am33xx() and then fall back to dmtimer?
> > Just to prove this, everything works here, I modified the code for this
> > and tested it on both AM335x EVM and AM37xEVM and it works fine for me.
> >
> >
> > Any comments?? OR Better approach? OR anything which I am missing here?
> >
> You can register both the clock sources together with different
> rating. Based on rating
> timer code will automatically pick the better clock-source of two.
> Ratings is based on the resolution of the timer.
>
Santosh,
- Still current compile time implementation must be changed/cleaned, right?
- The 32k timer doesn't exist at all on AM33xx device, so you can not
(and should not) Register this timer.
Thanks,
Vaibhav
> That should remove the CONFIG option depedency.
>
> Regards
> Santosh
>
More information about the linux-arm-kernel
mailing list