Re: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-05-01 Thread Kevin Hilman
Hiremath, Vaibhav hvaib...@ti.com writes:

 On Fri, Apr 27, 2012 at 04:08:07, Paul Walmsley wrote:
 On Thu, 26 Apr 2012, Paul Walmsley wrote:
 
  Okay, thanks for testing.  Please do update this patch to use 
  omap_hwmod_enable(), etc.; see for example omap_dm_timer_init_one().
 
 And, just to be explicit, the ioremap(), clk_get(), and clk_enable() 
 should no longer be needed for OMAP2+, once you add the 
 omap_hwmod_enable().
 

 What about OMAP1 architecture? Will it work? 

You'll need to move the ioremap/clk* usage into OMAP1 code
(mach-omap1/timer32k.c), and move the omap_hwmod_enable() into OMAP2+
code (mach-omap2/timer.c).

Then make the omap_init_clocksource_32k() just take the base address.

If counter_32k were a real driver (and it should be) this is how things
would work.  For example, the GPIO driver is shared between OMAP1 and
OMAP2+ and any SoC specific init is done in the SoC specific device init
code instead of the driver.

Hope this helps,

Kevin

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


Re: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Paul Walmsley
Hi

a question

On Wed, 25 Apr 2012, Vaibhav Hiremath wrote:

 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 AM continue to use the same code.
 
 Also, 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.

...

 -int __init omap_init_clocksource_32k(void)
 +/**
 + * omap_init_clocksource_32k - setup and register counter 32k as a
 + * kernel clocksource
 + * @pbase: base addr of counter_32k module
 + * @size: size of counter_32k to map
 + *
 + * Returns 0 upon success or negative error code upon failure.
 + *
 + */
 +int __init omap_init_clocksource_32k(u32 pbase, unsigned long size)
  {
 - static char err[] __initdata = KERN_ERR
 - %s: can't register clocksource!\n;
 -
 - if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
 - u32 pbase;
 - unsigned long size = SZ_4K;
 - void __iomem *base;
 - struct clk *sync_32k_ick;
 -
 - if (cpu_is_omap16xx()) {
 - pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
 - size = SZ_1K;
 - } else if (cpu_is_omap2420())
 - pbase = OMAP2420_32KSYNCT_BASE + 0x10;
 - else if (cpu_is_omap2430())
 - pbase = OMAP2430_32KSYNCT_BASE + 0x10;
 - else if (cpu_is_omap34xx())
 - pbase = OMAP3430_32KSYNCT_BASE + 0x10;
 - else if (cpu_is_omap44xx())
 - pbase = OMAP4430_32KSYNCT_BASE + 0x10;
 - else
 - return -ENODEV;
 -
 - /* For this to work we must have a static mapping in io.c for 
 this area */
 - base = ioremap(pbase, size);
 - if (!base)
 - return -ENODEV;
 -
 - sync_32k_ick = clk_get(NULL, omap_32ksync_ick);
 - if (!IS_ERR(sync_32k_ick))
 - clk_enable(sync_32k_ick);
 -
 - timer_32k_base = base;
 -
 - /*
 -  * 12 rough estimate from the calculations in
 -  * __clocksource_updatefreq_scale.
 -  */
 - clocks_calc_mult_shift(persistent_mult, persistent_shift,
 - 32768, NSEC_PER_SEC, 12);
 -
 - if (clocksource_mmio_init(base, 32k_counter, 32768, 250, 32,
 -   clocksource_mmio_readl_up))
 - printk(err, 32k_counter);
 -
 - setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
 + int ret;
 + void __iomem *base;
 + struct clk *sync32k_ick;
 +
 + if (!pbase || !size)
 + return -ENODEV;
 + /*
 +  * For this to work we must have a static mapping in io.c
 +  * for this area
 +  */
 + base = ioremap(pbase, size);
 + if (!base) {
 + pr_err(32k_counter: failed to map base addr\n);
 + return -ENODEV;
   }
 - return 0;
 +
 + sync32k_ick = clk_get(NULL, omap_32ksync_ick);
 + if (!IS_ERR(sync32k_ick))
 + clk_enable(sync32k_ick);

You've added hwmod data for this IP block, which is good.  This will 
presumably cause the IP block to be idled on boot.  But you haven't 
converted this code to use either the hwmod enable code -- just using 
clk_get() isn't enough.  (Better would be to use a driver and the PM 
runtime functions, of course, but maybe this runs too early?)

If the 32k sync timer is in OCP force-idle, then that might produce the 
hangs you're seeing.


- Paul
--
To unsubscribe from this 

RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Hiremath, Vaibhav
On Thu, Apr 26, 2012 at 20:40:34, Paul Walmsley wrote:
 Hi
 
 a question
 
 On Wed, 25 Apr 2012, Vaibhav Hiremath wrote:
 
  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 AM continue to use the same code.
  
  Also, 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.
 
 ...
 
  -int __init omap_init_clocksource_32k(void)
  +/**
  + * omap_init_clocksource_32k - setup and register counter 32k as a
  + * kernel clocksource
  + * @pbase: base addr of counter_32k module
  + * @size: size of counter_32k to map
  + *
  + * Returns 0 upon success or negative error code upon failure.
  + *
  + */
  +int __init omap_init_clocksource_32k(u32 pbase, unsigned long size)
   {
  -   static char err[] __initdata = KERN_ERR
  -   %s: can't register clocksource!\n;
  -
  -   if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
  -   u32 pbase;
  -   unsigned long size = SZ_4K;
  -   void __iomem *base;
  -   struct clk *sync_32k_ick;
  -
  -   if (cpu_is_omap16xx()) {
  -   pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
  -   size = SZ_1K;
  -   } else if (cpu_is_omap2420())
  -   pbase = OMAP2420_32KSYNCT_BASE + 0x10;
  -   else if (cpu_is_omap2430())
  -   pbase = OMAP2430_32KSYNCT_BASE + 0x10;
  -   else if (cpu_is_omap34xx())
  -   pbase = OMAP3430_32KSYNCT_BASE + 0x10;
  -   else if (cpu_is_omap44xx())
  -   pbase = OMAP4430_32KSYNCT_BASE + 0x10;
  -   else
  -   return -ENODEV;
  -
  -   /* For this to work we must have a static mapping in io.c for 
  this area */
  -   base = ioremap(pbase, size);
  -   if (!base)
  -   return -ENODEV;
  -
  -   sync_32k_ick = clk_get(NULL, omap_32ksync_ick);
  -   if (!IS_ERR(sync_32k_ick))
  -   clk_enable(sync_32k_ick);
  -
  -   timer_32k_base = base;
  -
  -   /*
  -* 12 rough estimate from the calculations in
  -* __clocksource_updatefreq_scale.
  -*/
  -   clocks_calc_mult_shift(persistent_mult, persistent_shift,
  -   32768, NSEC_PER_SEC, 12);
  -
  -   if (clocksource_mmio_init(base, 32k_counter, 32768, 250, 32,
  - clocksource_mmio_readl_up))
  -   printk(err, 32k_counter);
  -
  -   setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
  +   int ret;
  +   void __iomem *base;
  +   struct clk *sync32k_ick;
  +
  +   if (!pbase || !size)
  +   return -ENODEV;
  +   /*
  +* For this to work we must have a static mapping in io.c
  +* for this area
  +*/
  +   base = ioremap(pbase, size);
  +   if (!base) {
  +   pr_err(32k_counter: failed to map base addr\n);
  +   return -ENODEV;
  }
  -   return 0;
  +
  +   sync32k_ick = clk_get(NULL, omap_32ksync_ick);
  +   if (!IS_ERR(sync32k_ick))
  +   clk_enable(sync32k_ick);
 
 You've added hwmod data for this IP block, which is good.  This will 
 presumably cause the IP block to be idled on boot.  But you haven't 
 converted this code to use either the hwmod enable code -- just using 
 clk_get() isn't enough.  (Better would be to use a driver and the PM 
 runtime functions, of course, but maybe this runs too early?)

Yes, this runs very early in the boot sequence.

 
 If 

RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Hiremath, Vaibhav
On Thu, Apr 26, 2012 at 20:40:34, Paul Walmsley wrote:
 Hi
 
 a question
 
 On Wed, 25 Apr 2012, Vaibhav Hiremath wrote:
 
snip
  +
  +   sync32k_ick = clk_get(NULL, omap_32ksync_ick);
  +   if (!IS_ERR(sync32k_ick))
  +   clk_enable(sync32k_ick);
 
 You've added hwmod data for this IP block, which is good.  This will 
 presumably cause the IP block to be idled on boot.  But you haven't 
 converted this code to use either the hwmod enable code -- just using 
 clk_get() isn't enough.  (Better would be to use a driver and the PM 
 runtime functions, of course, but maybe this runs too early?)
 
 If the 32k sync timer is in OCP force-idle, then that might produce the 
 hangs you're seeing.
 

I tried disabling all idle related flags in hwmod entry but no change in 
observation, kernel still hangs.

I even conformed the register content by connecting debugger, and it is set 
to No-idle state.

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


RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Paul Walmsley
On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote:

 On Thu, Apr 26, 2012 at 20:40:34, Paul Walmsley wrote:
  On Wed, 25 Apr 2012, Vaibhav Hiremath wrote:
  
 snip
   +
   + sync32k_ick = clk_get(NULL, omap_32ksync_ick);
   + if (!IS_ERR(sync32k_ick))
   + clk_enable(sync32k_ick);
  
  You've added hwmod data for this IP block, which is good.  This will 
  presumably cause the IP block to be idled on boot.  But you haven't 
  converted this code to use either the hwmod enable code -- just using 
  clk_get() isn't enough.  (Better would be to use a driver and the PM 
  runtime functions, of course, but maybe this runs too early?)
  
  If the 32k sync timer is in OCP force-idle, then that might produce the 
  hangs you're seeing.
  
 
 I tried disabling all idle related flags in hwmod entry but no change in 
 observation, kernel still hangs.
 
 I even conformed the register content by connecting debugger, and it is set 
 to No-idle state.

Okay, thanks for testing.  Please do update this patch to use 
omap_hwmod_enable(), etc.; see for example omap_dm_timer_init_one().


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


Re: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Kevin Hilman
Vaibhav Hiremath hvaib...@ti.com writes:

 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 AM continue to use the same code.

 Also, 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.

 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
 Cc: Ming Lei tom.leim...@gmail.com
 ---
 NOTE: This patch is same as V3, without any code changes. Only
   commit description has been modified.

I assume you menat v4 here, since you also change the ioremap() range in
this version compared to v3?

Also, I boot tested this on OMAP1 (5912/OSK) and OMAP3530/Overo and with
the fix for clocksource_mmio_init() below, it worked fine.  I also
tested the cmdline override on OMAP3.

That being said, a few minor comments below...

  arch/arm/mach-omap1/timer32k.c   |6 ++-
  arch/arm/mach-omap2/timer.c  |   99 +--
  arch/arm/plat-omap/counter_32k.c |  108 
 +++---
  arch/arm/plat-omap/include/plat/common.h |2 +-
  4 files changed, 138 insertions(+), 77 deletions(-)

 diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
 index 325b9a0..6262e11 100644
 --- a/arch/arm/mach-omap1/timer32k.c
 +++ b/arch/arm/mach-omap1/timer32k.c
 @@ -71,6 +71,7 @@

  /* 16xx specific defines */
  #define OMAP1_32K_TIMER_BASE 0xfffb9000
 +#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
  #define OMAP1_32K_TIMER_CR   0x08
  #define OMAP1_32K_TIMER_TVR  0x00
  #define OMAP1_32K_TIMER_TCR  0x04
 @@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
   */
  bool __init omap_32k_timer_init(void)
  {
 - omap_init_clocksource_32k();
 + u32 pbase;
 +
 + pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;

Compile testing on OMAP1 (using omap1_defconfig) gives a few compiler
warnings:

/work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c: In function 
'omap_32k_timer_init':
/work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c:190:37: warning: 
pointer/integer type mismatch in conditional expression [enabled by default]
/work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c:190:8: warning: assignment 
makes integer from pointer without a cast [enabled by default]

 + omap_init_clocksource_32k(pbase, SZ_1K);

Should this be called if pbase == NULL?

If this clocksource does fail, how does the MPU clocksource get
registered?

Looking a bit closer, it appears the whole MPU vs. 32k init is even more
messed up on OMAP1 than OMAP2+ and needs some cleanup.  However,
it's not directly related to this series since it was messed up before
your series.

   omap_init_32k_timer();
   return true;
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index ecec873..d720f58 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -243,22 +243,8 @@ static void __init omap2_gp_clockevent_init(int 
 gptimer_id,
  }

  /* Clocksource code */
 -
 -#ifdef CONFIG_OMAP_32K_TIMER
 -/*
 - * When 32k-timer is enabled, don't use GPTimer for clocksource
 - * instead, just leave default clocksource which uses the 32k
 - * sync counter.  See clocksource setup in plat-omap/counter_32k.c
 - */
 -
 -static void __init omap2_gp_clocksource_init(int 

RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Paul Walmsley
On Thu, 26 Apr 2012, Paul Walmsley wrote:

 Okay, thanks for testing.  Please do update this patch to use 
 omap_hwmod_enable(), etc.; see for example omap_dm_timer_init_one().

And, just to be explicit, the ioremap(), clk_get(), and clk_enable() 
should no longer be needed for OMAP2+, once you add the 
omap_hwmod_enable().


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


RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Hiremath, Vaibhav
On Fri, Apr 27, 2012 at 04:08:07, Paul Walmsley wrote:
 On Thu, 26 Apr 2012, Paul Walmsley wrote:
 
  Okay, thanks for testing.  Please do update this patch to use 
  omap_hwmod_enable(), etc.; see for example omap_dm_timer_init_one().
 
 And, just to be explicit, the ioremap(), clk_get(), and clk_enable() 
 should no longer be needed for OMAP2+, once you add the 
 omap_hwmod_enable().
 

What about OMAP1 architecture? Will it work? 

Thanks,
Vaibhav

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


RE: [PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-26 Thread Hiremath, Vaibhav
On Fri, Apr 27, 2012 at 03:56:56, Hilman, Kevin wrote:
 Vaibhav Hiremath hvaib...@ti.com writes:
 
  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 AM continue to use the same code.
 
  Also, 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.
 
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
  Cc: Benoit Cousson b-cous...@ti.com
  Cc: Tony Lindgren t...@atomide.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@ti.com
  Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
  Cc: Ming Lei tom.leim...@gmail.com
  ---
  NOTE: This patch is same as V3, without any code changes. Only
commit description has been modified.
 
 I assume you menat v4 here, since you also change the ioremap() range in
 this version compared to v3?
 

Yes, I meant V4 here.

 Also, I boot tested this on OMAP1 (5912/OSK) and OMAP3530/Overo and with
 the fix for clocksource_mmio_init() below, it worked fine.  I also
 tested the cmdline override on OMAP3.
 

Great, thanks for testing it on OMAP1.

 That being said, a few minor comments below...
 
   arch/arm/mach-omap1/timer32k.c   |6 ++-
   arch/arm/mach-omap2/timer.c  |   99 +--
   arch/arm/plat-omap/counter_32k.c |  108 
  +++---
   arch/arm/plat-omap/include/plat/common.h |2 +-
   4 files changed, 138 insertions(+), 77 deletions(-)
 
  diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
  index 325b9a0..6262e11 100644
  --- a/arch/arm/mach-omap1/timer32k.c
  +++ b/arch/arm/mach-omap1/timer32k.c
  @@ -71,6 +71,7 @@
 
   /* 16xx specific defines */
   #define OMAP1_32K_TIMER_BASE   0xfffb9000
  +#define OMAP1_32KSYNC_TIMER_BASE   0xfffbc400
   #define OMAP1_32K_TIMER_CR 0x08
   #define OMAP1_32K_TIMER_TVR0x00
   #define OMAP1_32K_TIMER_TCR0x04
  @@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
*/
   bool __init omap_32k_timer_init(void)
   {
  -   omap_init_clocksource_32k();
  +   u32 pbase;
  +
  +   pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
 
 Compile testing on OMAP1 (using omap1_defconfig) gives a few compiler
 warnings:
 
 /work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c: In function 
 'omap_32k_timer_init':
 /work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c:190:37: warning: 
 pointer/integer type mismatch in conditional expression [enabled by default]
 /work/kernel/omap/dev/arch/arm/mach-omap1/timer32k.c:190:8: warning: 
 assignment makes integer from pointer without a cast [enabled by default]
 

Oops. I only tested with omap2plus_defconfig, I should have also checked 
omap1_defconfig. I will fix this in next version.

  +   omap_init_clocksource_32k(pbase, SZ_1K);
 
 Should this be called if pbase == NULL?
 

The first thing in the function we do is to check for pbase != NULL, and
returns error; so I did not put check again here.


 If this clocksource does fail, how does the MPU clocksource get
 registered?

I believe, the original code itself was written with the assumption that,
there will not be any failures from omap_32k_timer_init(), I did not modify
it, since I can not test it here at my end. Don't have omap1 board with me.

If you help me in validating it, I will create a patch for this cleanup.

 
 Looking a bit closer, it appears the whole MPU vs. 32k init is even more
 

[PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

2012-04-25 Thread 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).
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 AM continue to use the same code.

Also, 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.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
NOTE: This patch is same as V3, without any code changes. Only
  commit description has been modified.

 arch/arm/mach-omap1/timer32k.c   |6 ++-
 arch/arm/mach-omap2/timer.c  |   99 +--
 arch/arm/plat-omap/counter_32k.c |  108 +++---
 arch/arm/plat-omap/include/plat/common.h |2 +-
 4 files changed, 138 insertions(+), 77 deletions(-)

diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 325b9a0..6262e11 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -71,6 +71,7 @@

 /* 16xx specific defines */
 #define OMAP1_32K_TIMER_BASE   0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE   0xfffbc400
 #define OMAP1_32K_TIMER_CR 0x08
 #define OMAP1_32K_TIMER_TVR0x00
 #define OMAP1_32K_TIMER_TCR0x04
@@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
  */
 bool __init omap_32k_timer_init(void)
 {
-   omap_init_clocksource_32k();
+   u32 pbase;
+
+   pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+   omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();

return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ecec873..d720f58 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -243,22 +243,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 }

 /* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter.  See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
-   omap_init_clocksource_32k();
-}
-
-#else
-
 static struct omap_dm_timer clksrc;
+static bool use_gptimer_clksrc;

 /*
  * clocksource
@@ -285,7 +271,33 @@ static u32 notrace dmtimer_read_sched_clock(void)
 }

 /* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static int __init omap2_sync32k_clocksource_init(void)
+{
+   int ret;
+   struct omap_hwmod *oh;
+   struct resource res;
+   const char *oh_name = counter_32k;
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh || oh-slaves_cnt == 0)
+   return -ENODEV;
+
+   ret = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM, NULL, res);
+   if (ret) {
+   pr_warn(%s: failed to get counter_32k resource (%d)\n,
+   __func__, ret);
+   return ret;
+   }
+
+   ret = omap_init_clocksource_32k(res.start, resource_size(res));
+   if (ret)
+   pr_warn(%s: failed to initialize counter_32k (%d)\n,
+   __func__, ret);
+
+   return ret;
+}
+
+static void __init omap2_gptimer_clocksource_init(int