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

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

[Hiremath, Vaibhav]

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?

Thanks,
Vaibhav

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

[Shilimkar, Santosh]

On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav <hvaibhav@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.

That should remove the CONFIG option depedency.

Regards
Santosh

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

[Hiremath, Vaibhav]

On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav <hvaibhav@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
> 

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

[Shilimkar, Santosh]

On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav@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@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.

Regards
Santosh

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@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@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
> 

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

[Cousson, Benoit]

On 1/13/2012 1:21 PM, Hiremath, Vaibhav 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,

A series was sent to do that by Felipe last year, but we somehow forgot 
to rebase it on newer kernel and thus never reposted it.

Benoit

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

[Hiremath, Vaibhav]

On Fri, Jan 13, 2012 at 20:49:35, Cousson, Benoit wrote:
> On 1/13/2012 1:21 PM, Hiremath, Vaibhav 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,
> 
> A series was sent to do that by Felipe last year, but we somehow forgot 
> to rebase it on newer kernel and thus never reposted it.
> 

If you are ok, I can help you here. Can you please point me to git repo for
the same.

And also, this is important for AM33xx support in mainline.

Thanks,
Vaibhav

> Benoit
> 

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

[Cousson, Benoit]

On 1/13/2012 4:52 PM, Hiremath, Vaibhav wrote:
> On Fri, Jan 13, 2012 at 20:49:35, Cousson, Benoit wrote:

[...]

>> A series was sent to do that by Felipe last year, but we somehow forgot
>> to rebase it on newer kernel and thus never reposted it.
>
> If you are ok, I can help you here.

Thanks it will be cool if you can fix that series.

> Can you please point me to git repo for
> the same.
>
> And also, this is important for AM33xx support in mainline.

Here is the link to the original series.

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg37403.html

The hwmod format changed a lot since them, so it should be refreshed.

Regards,
Benoit

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

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120113 06:08]:
> On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote:
> > On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> >> > ? ...
> >> > ? };
> >> >
> >> > ? 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?

Why don't you just add a new entry to mach-omap2/timer.c using the OMAP_SYS_TIMER
macro?

See for example the omap3_secure timer set up. That should allow
specifying the clock source already.

Regards,

Tony

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

[Hiremath, Vaibhav]

On Fri, Jan 13, 2012 at 22:20:03, Tony Lindgren wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120113 06:08]:
> > On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote:
> > > On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> > >> > ? ...
> > >> > ? };
> > >> >
> > >> > ? 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?
> 
> Why don't you just add a new entry to mach-omap2/timer.c using the OMAP_SYS_TIMER
> macro?
> 
Tony,

The entry is already present in mach-olmap2/timer.c

OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
OMAP_SYS_TIMER(3_am33xx)


The issue is not related to this, more with respect to compile time 
Code -

#ifdef CONFIG_OMAP_32K_TIMER
static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
{
	32K TIMER code
}
#else
static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
{
	DMTIMER code
}
#endif

Omap2plus_defconfig enabled option "CONFIG_OMAP_32K_TIMER", so from
Multi-omap point of view it will break AM335x.

Thanks,
Vaibhav

> See for example the omap3_secure timer set up. That should allow
> specifying the clock source already.
> 
> Regards,
> 
> Tony
>