RE: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Fri, Apr 27, 2012 at 02:13:10, Dill, Russ wrote: On Thu, Apr 26, 2012 at 11:33 AM, Kevin Hilman khil...@ti.com wrote: Vaibhav Hiremath hvaib...@ti.com writes: If so, please reply with your Tested-by. Tested-by: Russ Dill russ.d...@ti.com All three patches in series boot tested on: Beagleboard xM Beagleboard B4 Mistral AM37X-EVM Thanks Russ, helping me out in validating this. I have also tested it on AM37xEVM platform and can conform that this fixes the issue. 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote: On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. 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 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 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? With no patches applied it boots, with 1/3 applied it boots, with 2/3 applied it boots, with 3/3 applied it gets hung. I also tested on my beagleboard b4, that booted fine. You mean to say, on Beagleboard it boots up fine. And same fails on EVM? 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Wed, Apr 25, 2012 at 11:23 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote: On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. 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 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 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? With no patches applied it boots, with 1/3 applied it boots, with 2/3 applied it boots, with 3/3 applied it gets hung. I also tested on my beagleboard b4, that booted fine. You mean to say, on Beagleboard it boots up fine. And same fails on EVM? yes -- 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 13:15:18, Russ Dill wrote:
On Wed, Apr 25, 2012 at 11:23 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote:
On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote:
On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com
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.
Snip
You mean to say, on Beagleboard it boots up fine. And same fails on EVM?
yes
I am able to reproduce this issue, and it seems the issue is really weird
and I am completely clueless here.
With below patch/change it always works, 100% success. The moment I add 0x10
offset to the ioremaped virtual base address, gone...95% of the time it
fails.
I have observed that, the execution always stays at wfi (default_idle)
thread. Really strange behavior...and I am clueless now.
- The 32k sync timer address space is part of iotable.
- The ioremap() internally masks the addr to page aligned addr and gets pfn,
At the end, offset is being added. So I don't really understand how is it
different than adding offset before and after ioremap().
Also, this issue is nothing to do with my patch, it also happens with the
original code.
Just add 0x10 offset after ioremap(), and booom (95% of the time)
--Patch which works (on top of this patch-series)--
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 3e3cdab..b0ef8ce 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -90,6 +90,7 @@ int __init omap_init_clocksource_32k(u32 pbase, unsigned long
size)
* For this to work we must have a static mapping in io.c
* for this area
*/
+ pbase = pbase + OMAP2_32KSYNCNT_CR_OFF;
base = ioremap(pbase, size);
if (!base) {
pr_err(32k_counter: failed to map base addr\n);
@@ -100,7 +101,7 @@ int __init omap_init_clocksource_32k(u32 pbase, unsigned
long size)
if (!IS_ERR(sync32k_ick))
clk_enable(sync32k_ick);
- sync32k_cnt_reg = base + OMAP2_32KSYNCNT_CR_OFF;
+ sync32k_cnt_reg = base;
/*
* 12 rough estimate from the calculations in
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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Hi Vaibhav, Russ, On 04/26/2012 08:46 AM, Hiremath, Vaibhav wrote: On Thu, Apr 26, 2012 at 13:15:18, Russ Dill wrote: On Wed, Apr 25, 2012 at 11:23 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote: On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Snip You mean to say, on Beagleboard it boots up fine. And same fails on EVM? yes I am able to reproduce this issue, and it seems the issue is really weird and I am completely clueless here. With below patch/change it always works, 100% success. The moment I add 0x10 offset to the ioremaped virtual base address, gone...95% of the time it fails. I have observed that, the execution always stays at wfi (default_idle) thread. Really strange behavior...and I am clueless now. - The 32k sync timer address space is part of iotable. - The ioremap() internally masks the addr to page aligned addr and gets pfn, At the end, offset is being added. So I don't really understand how is it different than adding offset before and after ioremap(). Also, this issue is nothing to do with my patch, it also happens with the original code. Just add 0x10 offset after ioremap(), and booom (95% of the time) --Patch which works (on top of this patch-series)-- diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 3e3cdab..b0ef8ce 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -90,6 +90,7 @@ int __init omap_init_clocksource_32k(u32 pbase, unsigned long size) * For this to work we must have a static mapping in io.c * for this area */ + pbase = pbase + OMAP2_32KSYNCNT_CR_OFF; base = ioremap(pbase, size); What is size set to in the failing case on the am37xx device? Any chance we are not mapping enough space? Cheers Jon -- 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 21:28:15, Hunter, Jon wrote: Hi Vaibhav, Russ, On 04/26/2012 08:46 AM, Hiremath, Vaibhav wrote: On Thu, Apr 26, 2012 at 13:15:18, Russ Dill wrote: On Wed, Apr 25, 2012 at 11:23 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote: On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Snip You mean to say, on Beagleboard it boots up fine. And same fails on EVM? yes I am able to reproduce this issue, and it seems the issue is really weird and I am completely clueless here. With below patch/change it always works, 100% success. The moment I add 0x10 offset to the ioremaped virtual base address, gone...95% of the time it fails. I have observed that, the execution always stays at wfi (default_idle) thread. Really strange behavior...and I am clueless now. - The 32k sync timer address space is part of iotable. - The ioremap() internally masks the addr to page aligned addr and gets pfn, At the end, offset is being added. So I don't really understand how is it different than adding offset before and after ioremap(). Also, this issue is nothing to do with my patch, it also happens with the original code. Just add 0x10 offset after ioremap(), and booom (95% of the time) --Patch which works (on top of this patch-series)-- diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 3e3cdab..b0ef8ce 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -90,6 +90,7 @@ int __init omap_init_clocksource_32k(u32 pbase, unsigned long size) * For this to work we must have a static mapping in io.c * for this area */ + pbase = pbase + OMAP2_32KSYNCNT_CR_OFF; base = ioremap(pbase, size); What is size set to in the failing case on the am37xx device? Any chance we are not mapping enough space? I do not think it is related to mapping size. I have already explored this path. 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
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). [...] + + sync32k_ick = clk_get(NULL, omap_32ksync_ick); + if (!IS_ERR(sync32k_ick)) + clk_enable(sync32k_ick); + + sync32k_cnt_reg = base + OMAP2_32KSYNCNT_CR_OFF; + + /* + * 12 rough estimate from the calculations in + * __clocksource_updatefreq_scale. + */ + clocks_calc_mult_shift(persistent_mult, persistent_shift, + 32768, NSEC_PER_SEC, 12); + + ret = clocksource_mmio_init(base, 32k_counter, 32768, 250, 32, + clocksource_mmio_readl_up); After discussing this a bit with Vaibhav offline, we found that 'base' here should be sync32k_cnt_reg. Can you guys that were seeing the hang confirm that that fixes the issue? If so, please reply with your Tested-by. Thanks, 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On 04/26/2012 11:33 AM, Kevin Hilman wrote: Vaibhav Hiremathhvaib...@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). [...] + + sync32k_ick = clk_get(NULL, omap_32ksync_ick); + if (!IS_ERR(sync32k_ick)) + clk_enable(sync32k_ick); + + sync32k_cnt_reg = base + OMAP2_32KSYNCNT_CR_OFF; + + /* +* 12 rough estimate from the calculations in +* __clocksource_updatefreq_scale. +*/ + clocks_calc_mult_shift(persistent_mult,persistent_shift, + 32768, NSEC_PER_SEC, 12); + + ret = clocksource_mmio_init(base, 32k_counter, 32768, 250, 32, + clocksource_mmio_readl_up); After discussing this a bit with Vaibhav offline, we found that 'base' here should be sync32k_cnt_reg. Sorry, this was confusing. To be more specific, s/base/sync32k_cnt_reg/ in the clocksource_mmio_init line above. Kevin Can you guys that were seeing the hang confirm that that fixes the issue? If so, please reply with your Tested-by. Thanks, 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 -- 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 11:33 AM, Kevin Hilman khil...@ti.com 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). [...] + + sync32k_ick = clk_get(NULL, omap_32ksync_ick); + if (!IS_ERR(sync32k_ick)) + clk_enable(sync32k_ick); + + sync32k_cnt_reg = base + OMAP2_32KSYNCNT_CR_OFF; + + /* + * 12 rough estimate from the calculations in + * __clocksource_updatefreq_scale. + */ + clocks_calc_mult_shift(persistent_mult, persistent_shift, + 32768, NSEC_PER_SEC, 12); + + ret = clocksource_mmio_init(base, 32k_counter, 32768, 250, 32, + clocksource_mmio_readl_up); After discussing this a bit with Vaibhav offline, we found that 'base' here should be sync32k_cnt_reg. Can you guys that were seeing the hang confirm that that fixes the issue? If so, please reply with your Tested-by. Tested-by: Russ Dill russ.d...@ti.com All three patches in series boot tested on: Beagleboard xM Beagleboard B4 Mistral AM37X-EVM -- 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Tue, Apr 24, 2012 at 21:50:16, Tony Lindgren wrote:
Thanks Tony for review comments, my response in-lined below -
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120424 02:54]:
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.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
For some cases sys clock based timer is still valid if you don't
care about PM. In that case deeper idle states need to be disabled,
not the timer as discussed earlier. Please update the comments accordingly.
Ok, I will add below statement,
Also, in order to use option 2, deeper idle stated MUST be disabled.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Maybe just say: We must support both sync timer and gptimer based
clocksource as some AM33XX hardware does not have the sync timer.
Ok, I can change the description accordingly.
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 kernel parameter (clocksource=) to override
Maybe say: Use standard kernel parameter (clocksource=)...
Ditto, I will change the description accordingly.
--- 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;
Has this patch been tested on omap1?
I do not have omap1 board with me, so I can not test it. If somebody can
provide some help here, that would be really great?
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -510,3 +540,28 @@ static int __init omap2_dm_timer_init(void)
return 0;
}
arch_initcall(omap2_dm_timer_init);
+
+/**
+ * omap2_override_clocksource - clocksource override with user
configuration
+ *
+ * Allows user to override default clocksource, using kernel parameter
+ * clocksource=gp timer
+ *
+ * Note that, here we are using same standard kernel parameter
clocksource=,
+ * and not introducing any OMAP specific interface.
+ */
+static int __init omap2_override_clocksource(char *str)
+{
+ if (!str)
+ return 0;
+ /*
+* For OMAP architecture, we only have two options
+*- sync_32k (default)
+*- gp timer
+*/
+ if (!strcmp(str, gp timer))
+ use_gptimer_clksrc = true;
+
+ return 0;
+}
+early_param(clocksource, omap2_override_clocksource);
Should say For omap2plus architectures and should say three options.
If the sys clock based timer is not currently supported, please mention
that in the comments.
gp timer above is nothing but, sys_clock based gptimer option only. May be I
should add the source in bracket or something?
Like,
*- sync_32k (default)
*- gp timer (sys_clock)
Thanks,
Vaibhav
Regards,
Tony
--
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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. 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 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 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig ## Booting kernel from Legacy Image at 80007fc0 ... Image Name: Linux-3.4.0-rc3-ktest-11789-gea1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3360576 Bytes = 3.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK XIP Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc3-ktest-11789-gea133e0 (russ@russ-laptop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #9 SMP Wed Apr 25 21:13:16 MST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/1000 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0e0c000 s11456 r8192 d13120 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs nfsroot=192.168.1.143:/var/datastore/exports/192.168.1.20,nolock rw ip=dhcp [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 246504k/246504k available, 15640k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05cced4 (5908 kB) [0.00] .init : 0xc05cd000 - 0xc061acc0 ( 312 kB) [0.00] .data : 0xc061c000 - 0xc06b0cd8 ( 596 kB) [0.00].bss : 0xc06b0cfc - 0xc0c050e0 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ...
RE: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. 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 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 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com 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. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. 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 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 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? With no patches applied it boots, with 1/3 applied it boots, with 2/3 applied it boots, with 3/3 applied it gets hung. I also tested on my beagleboard b4, that booted fine. -- 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
[PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
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 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
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
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..2afc4ab 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 gptimer_id,
const char *fck_source)
{
int res;
@@ -293,9
Re: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120424 02:54]:
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.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
For some cases sys clock based timer is still valid if you don't
care about PM. In that case deeper idle states need to be disabled,
not the timer as discussed earlier. Please update the comments accordingly.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Maybe just say: We must support both sync timer and gptimer based
clocksource as some AM33XX hardware 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 kernel parameter (clocksource=) to override
Maybe say: Use standard kernel parameter (clocksource=)...
--- 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;
+ omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();
return true;
Has this patch been tested on omap1?
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -510,3 +540,28 @@ static int __init omap2_dm_timer_init(void)
return 0;
}
arch_initcall(omap2_dm_timer_init);
+
+/**
+ * omap2_override_clocksource - clocksource override with user configuration
+ *
+ * Allows user to override default clocksource, using kernel parameter
+ * clocksource=gp timer
+ *
+ * Note that, here we are using same standard kernel parameter
clocksource=,
+ * and not introducing any OMAP specific interface.
+ */
+static int __init omap2_override_clocksource(char *str)
+{
+ if (!str)
+ return 0;
+ /*
+ * For OMAP architecture, we only have two options
+ *- sync_32k (default)
+ *- gp timer
+ */
+ if (!strcmp(str, gp timer))
+ use_gptimer_clksrc = true;
+
+ return 0;
+}
+early_param(clocksource, omap2_override_clocksource);
Should say For omap2plus architectures and should say three options.
If the sys clock based timer is not currently supported, please mention
that in the comments.
Regards,
Tony
--
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
