omap clocksource timer selection: dmtimer OR 32K-Sync timer

[Hiremath, Vaibhav]

On Fri, Jan 13, 2012 at 20:11:04, Shilimkar, Santosh wrote:
> On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
> > 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?
> Yes. But that should be trivial.
> 
> >  - The 32k timer doesn't exist at all on AM33xx device, so you can not
> >   (and should not) Register this timer.
> >
> Well there are many init call happens on various IP's which are not supported
> across SOCs.
> 
> Look at L2X0 cache init for example. In such cases you just return by not
> doing anything on that hardware IP.
> 

Is "just return" happening through cpu_is_xxxx() check? I can see,

static int __init omap_l2_cache_init(void)
{
   ...
         /*
          * To avoid code running on other OMAPs in
          * multi-omap builds
          */
         if (!cpu_is_omap44xx())
                 return -ENODEV;
   ...
}


If yes, then, doesn't 'hwmod lookup' (may be DT in future) sound 
much better option?

Thanks,
Vaibhav

> Regards
> Santosh
>