ARM: OMAP: Make OMAP clocksource source selection runtime

OMAP1, omap_32k_timer_init() function always returns "true", irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code.

This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k().

Signed-off-by Vaibhav Hiremath <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Benoit Cousson <[email protected]>

---
This is new patch addition compared to original series (<=V5).

Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it.

 arch/arm/mach-omap1/common.h   |   10 +++++++++-
 arch/arm/mach-omap1/time.c     |   16 +---------------
 arch/arm/mach-omap1/timer32k.c |   13 +++++++++----
 3 files changed, 19 insertions(+), 20 deletions(-)

arch/arm/mach-omap1/common.h +0 -0

index 8cc616e..e8c9ad3 100644

arch/arm/mach-omap1/common.h +4 -0

+{
+	return -ENODEV;
+}
+#endif
 
 extern u32 omap_irq_flags;
 

arch/arm/mach-omap1/time.c +1 -15

index 4d8dd9a..4062480 100644
@@ -232,20 +232,6 @@ static inline void omap_mpu_timer_init(void)
 }
 #endif	/* CONFIG_OMAP_MPU_TIMER */
 
-static inline int omap_32k_timer_usable(void)
-{
-	int res = false;
-
-	if (cpu_is_omap730() || cpu_is_omap15xx())
-		return res;
-
-#ifdef CONFIG_OMAP_32K_TIMER
-	res = omap_32k_timer_init();
-#endif
-
-	return res;
-}
-
 /*
  * ---------------------------------------------------------------------------
  * Timer initialization

@@ -253,7 +239,7 @@ static inline int omap_32k_timer_usable(void)
  */
 static void __init omap1_timer_init(void)
 {
-	if (!omap_32k_timer_usable())
+	if (omap_32k_timer_init() != 0)
 		omap_mpu_timer_init();
 }
 

arch/arm/mach-omap1/timer32k.c +9 -5

index 325b9a0..e3613a8 100644
@@ -182,10 +182,15 @@ static __init void omap_init_32k_timer(void)
  * Timer initialization
  * ---------------------------------------------------------------------------
  */
-bool __init omap_32k_timer_init(void)
+int __init omap_32k_timer_init(void)
 {
-	omap_init_clocksource_32k();
-	omap_init_32k_timer();
+	int ret = -ENODEV;
 
-	return true;
+	if (cpu_is_omap16xx())
+		ret = omap_init_clocksource_32k();
+
+	if (!ret)
+		omap_init_32k_timer();
+
+	return ret;
 }
--

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 17 lines · Vaibhav Hiremath

OMAP1, omap_32k_timer_init() function always returns "true", irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code.

This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k().

Signed-off-by Vaibhav Hiremath <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Benoit Cousson <[email protected]>

---
This is new patch addition compared to original series (<=V5).

Quoted 3 lines

Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it.

I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer Kconfigs. Works fine, but needs small change below for compile warnings.

Otherwise, looks good.

Hi,

Quoted 25 lines · Kevin Hilman

Quoted 14 lines · Vaibhav Hiremath

OMAP1, omap_32k_timer_init() function always returns "true", irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code.

This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k().

Signed-off-by Vaibhav Hiremath <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Benoit Cousson <[email protected]>

Quoted 6 lines

---
This is new patch addition compared to original series (<=V5).

Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it.

I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer Kconfigs. Works fine, but needs small change below for compile

Quoted 2 lines

Otherwise, looks good.

We need at least one tested-by on some 15xx platform for these

Janusz, can you please give this series a try on your board too?

Depending on the bootloader, passing command-line arguments with spaces may have issues. Some bootloaders doesn't seem to pass along the quotes, passing only 'gp' part of the string, which leads to wrong clocksource override configuration.

So this patch changes "gp timer" => "gp_timer", for clockevent, clocksource and timer irq_handler.

Signed-off-by Vaibhav Hiremath <[email protected]>

Cc Santosh Shilimkar <[email protected]>

Cc Benoit Cousson <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Kevin Hilman <[email protected]>

Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options -

1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.

The optional gptimer based clocksource was added so that it can give the high precision than sync-timer, so expected usage was 2 and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of free-running clock as per clocksource need. It stops in low power states when sys_clock is cut. That makes gptimer based clocksource option useless for OMAP2/3/4 devices with sys_clock as a clock input. So, in order to use option 2, deeper idle state MUST be disabled.

Option 3 will still work but it is no better than 32K sync-timer based clocksource.

We must support both sync timer and gptimer based clocksource as some OMAP based derivative SoCs like AM33XX does not have the sync timer.

Considering above, make sync-timer and gptimer clocksource runtime selectable so that both OMAP and AMXXXX continue to use the same code.

And, in order to precisely configure/setup sched_clock for given clocksource, decision has to be made early enough in boot sequence.

So, the solution is,

Use standard kernel parameter ("clocksource=") to override default 32k_sync-timer, in addition to this, we also use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gptimer.

Also, moved low-level SoC specific init code to respective files, (mach-omap1/timer32k.c and mach-omap2/timer.c)

Signed-off-by Vaibhav Hiremath <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Reviewed-by Santosh Shilimkar <[email protected]>

Cc Benoit Cousson <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Tarun Kanti DebBarma <[email protected]>

Cc Ming Lei <[email protected]>

Quoted 10 lines · Vaibhav Hiremath

Signed-off-by Vaibhav Hiremath <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Reviewed-by Santosh Shilimkar <[email protected]>

Cc Benoit Cousson <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Tarun Kanti DebBarma <[email protected]>

Cc Ming Lei <[email protected]>

Reviewed-by Kevin Hilman <[email protected]>

Tested-by Kevin Hilman <[email protected]>

tested on OMAP3530/Overo with default 32k timer and cmdline override for GPtimer.

Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)

This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of "counter_32k", also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer.

if(use_gptimer_clksrc == true)

	gptimer clocksource init;
else if (counter_32 init == false)
	/* Fallback to gptimer */
	gptimer clocksource init(;

With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer.

This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms.

The patches are also available at (based on linux-omap/master) -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup

From 2a213a6d5f5894bc1c5262f2724508eaef21c7a5 Mon Sep 17 00:00:00 2001

Hi Vaibhav,

Quoted 21 lines · Vaibhav Hiremath

Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)

This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of "counter_32k", also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer.

if(use_gptimer_clksrc == true)

	gptimer clocksource init;
else if (counter_32 init == false)
	/* Fallback to gptimer */
	gptimer clocksource init(;

With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer.

Quoted 6 lines

This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms.

The patches are also available at (based on linux-omap/master) -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup

I was testing on OMAP4 and I found that the gptimer was always being set by default. I noticed that currently the HWMOD for counter_32k on OMAP4 is commented and hence was not being found. Please can you include the following with your series?

Quoted 31 lines · Jon

Hi Vaibhav,

Quoted 27 lines · Vaibhav Hiremath

Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)

This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of "counter_32k", also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer.

if(use_gptimer_clksrc == true)

	gptimer clocksource init;
else if (counter_32 init == false)
	/* Fallback to gptimer */
	gptimer clocksource init(;

With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer.

This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms.

The patches are also available at (based on linux-omap/master) -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup

Quoted 2 lines

I was testing on OMAP4 and I found that the gptimer was always being set by default. I noticed that currently the HWMOD for counter_32k on OMAP4 is commented and hence was not being found. Please can you include the following with your series?

The 32kcounter hwmod entry is already enabled in linux-omap/master branch.

Your baseline looks pretty old to me, are you not using linux-omap/master?

Hi Vaibhav,

Quoted 35 lines · Vaibhav

Quoted 33 lines · Jon

Hi Vaibhav,

Quoted 21 lines · Vaibhav Hiremath

Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)

This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of "counter_32k", also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer.

if(use_gptimer_clksrc == true)

	gptimer clocksource init;
else if (counter_32 init == false)
	/* Fallback to gptimer */
	gptimer clocksource init(;

With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer.

Quoted 6 lines

This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms.

The patches are also available at (based on linux-omap/master) -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup

I was testing on OMAP4 and I found that the gptimer was always being set by default. I noticed that currently the HWMOD for counter_32k on OMAP4 is commented and hence was not being found. Please can you include the following with your series?

Quoted 3 lines

The 32kcounter hwmod entry is already enabled in linux-omap/master branch.

Your baseline looks pretty old to me, are you not using linux-omap/master?

Ha! My "old" baseline is the latest mainline kernel ;-)

I guess this is a bit out-dated in terms of omap now. Sorry I missed that fact your patches were on top of the omap kernel in the changelog.