* [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. @ 2012-03-12 15:33 Santosh Shilimkar 2012-03-12 16:51 ` Kevin Hilman 0 siblings, 1 reply; 5+ messages in thread From: Santosh Shilimkar @ 2012-03-12 15:33 UTC (permalink / raw) To: linux-omap; +Cc: linux-arm-kernel, dave.long, Santosh Shilimkar On OMAP4, recently a synchronisation bug is discovered by hardware team, which leads to incorrect timer value read from 32K sync timer IP when the IP is comming out of idle. The issue is due to the synchronization methodology used in the SYNCTIMER IP. The value of the counter register in 32kHz domain is synchronized to the OCP domain register only at count up event, and if the OCP clock is switched off, the OCP register gets out of synch until the first count up event after the clock is switched back -at the next falling edge of the 32kHz clock. Further investigation revealed that it applies to gptimer1 and watchdog timer2 as well which may run on 32KHz. This patch fixes the issue for all the applicable modules. The BUG has not made it yet to the OMAP errata list and it is applicable to OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps. Reported-Tested-by: dave.long@linaro.org [dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer and helped to test this patch] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> --- arch/arm/mach-omap2/pm44xx.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..974f7ea 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -196,7 +196,7 @@ static void omap_default_idle(void) static int __init omap4_pm_init(void) { int ret; - struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm; + struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup; struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm; if (!cpu_is_omap44xx()) @@ -220,14 +220,19 @@ static int __init omap4_pm_init(void) * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as * expected. The hardware recommendation is to enable static * dependencies for these to avoid system lock ups or random crashes. + * The L4 wakeup depedency is added to workaround the OCP sync hardware + * BUG with 32K synctimer which lead to incorrect timer value read + * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which + * are part of L4 wakeup clockdomain. */ mpuss_clkdm = clkdm_lookup("mpuss_clkdm"); emif_clkdm = clkdm_lookup("l3_emif_clkdm"); l3_1_clkdm = clkdm_lookup("l3_1_clkdm"); l3_2_clkdm = clkdm_lookup("l3_2_clkdm"); l4_per_clkdm = clkdm_lookup("l4_per_clkdm"); + l4wkup = clkdm_lookup("l4_wkup_clkdm"); ducati_clkdm = clkdm_lookup("ducati_clkdm"); - if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) || (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) goto err2; @@ -235,6 +240,7 @@ static int __init omap4_pm_init(void) ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup); ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); if (ret) { -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. 2012-03-12 15:33 [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer Santosh Shilimkar @ 2012-03-12 16:51 ` Kevin Hilman 2012-03-13 8:47 ` Santosh Shilimkar 0 siblings, 1 reply; 5+ messages in thread From: Kevin Hilman @ 2012-03-12 16:51 UTC (permalink / raw) To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, dave.long Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On OMAP4, recently a synchronisation bug is discovered by hardware > team, which leads to incorrect timer value read from 32K sync timer > IP when the IP is comming out of idle. > > The issue is due to the synchronization methodology used in the SYNCTIMER IP. > The value of the counter register in 32kHz domain is synchronized to the OCP > domain register only at count up event, and if the OCP clock is switched off, > the OCP register gets out of synch until the first count up event after the > clock is switched back -at the next falling edge of the 32kHz clock. > > Further investigation revealed that it applies to gptimer1 and watchdog timer2 > as well which may run on 32KHz. This patch fixes the issue for all the > applicable modules. The changelog describes the problem ver well, but doesn't actually describe the fix (enable static dep.) Can you update the changelog do describe the fix, and why it fixes the problem. Thanks, Kevin > The BUG has not made it yet to the OMAP errata list and it is applicable to > OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps. > > Reported-Tested-by: dave.long@linaro.org > [dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer > and helped to test this patch] > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/mach-omap2/pm44xx.c | 10 ++++++++-- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c > index c264ef7..974f7ea 100644 > --- a/arch/arm/mach-omap2/pm44xx.c > +++ b/arch/arm/mach-omap2/pm44xx.c > @@ -196,7 +196,7 @@ static void omap_default_idle(void) > static int __init omap4_pm_init(void) > { > int ret; > - struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm; > + struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup; > struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm; > > if (!cpu_is_omap44xx()) > @@ -220,14 +220,19 @@ static int __init omap4_pm_init(void) > * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as > * expected. The hardware recommendation is to enable static > * dependencies for these to avoid system lock ups or random crashes. > + * The L4 wakeup depedency is added to workaround the OCP sync hardware > + * BUG with 32K synctimer which lead to incorrect timer value read > + * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which > + * are part of L4 wakeup clockdomain. > */ > mpuss_clkdm = clkdm_lookup("mpuss_clkdm"); > emif_clkdm = clkdm_lookup("l3_emif_clkdm"); > l3_1_clkdm = clkdm_lookup("l3_1_clkdm"); > l3_2_clkdm = clkdm_lookup("l3_2_clkdm"); > l4_per_clkdm = clkdm_lookup("l4_per_clkdm"); > + l4wkup = clkdm_lookup("l4_wkup_clkdm"); > ducati_clkdm = clkdm_lookup("ducati_clkdm"); > - if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || > + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) || > (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) > goto err2; > > @@ -235,6 +240,7 @@ static int __init omap4_pm_init(void) > ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); > ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); > ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); > + ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup); > ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); > ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); > if (ret) { ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. 2012-03-12 16:51 ` Kevin Hilman @ 2012-03-13 8:47 ` Santosh Shilimkar 2012-03-13 16:31 ` Kevin Hilman 0 siblings, 1 reply; 5+ messages in thread From: Santosh Shilimkar @ 2012-03-13 8:47 UTC (permalink / raw) To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, dave.long [-- Attachment #1: Type: text/plain, Size: 4999 bytes --] On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> On OMAP4, recently a synchronisation bug is discovered by hardware >> team, which leads to incorrect timer value read from 32K sync timer >> IP when the IP is comming out of idle. >> >> The issue is due to the synchronization methodology used in the SYNCTIMER IP. >> The value of the counter register in 32kHz domain is synchronized to the OCP >> domain register only at count up event, and if the OCP clock is switched off, >> the OCP register gets out of synch until the first count up event after the >> clock is switched back -at the next falling edge of the 32kHz clock. >> >> Further investigation revealed that it applies to gptimer1 and watchdog timer2 >> as well which may run on 32KHz. This patch fixes the issue for all the >> applicable modules. > > The changelog describes the problem ver well, but doesn't actually > describe the fix (enable static dep.) Can you update the changelog do > describe the fix, and why it fixes the problem. > Sure. Updated patch below. The idea is to ensure that synctimer is syncronised before software does any reads on the counter. The BUG will get fixed in future OMAP designs Attaching the patch in case thunderbird email client eats the tabs. Regards Santosh >From 2edeebbd434627d1d0a9d96f6c5bda044a68fa70 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar <santosh.shilimkar@ti.com> Date: Mon, 12 Mar 2012 20:34:45 +0530 Subject: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. On OMAP4, recently a synchronisation bug is discovered by hardware team, which leads to incorrect timer value read from 32K sync timer IP when the IP is comming out of idle. The issue is due to the synchronization methodology used in the SYNCTIMER IP. The value of the counter register in 32kHz domain is synchronized to the OCP domain register only at count up event, and if the OCP clock is switched off, the OCP register gets out of synch until the first count up event after the clock is switched back -at the next falling edge of the 32kHz clock. Further investigation revealed that it applies to gptimer1 and watchdog timer2 as well which may run on 32KHz. This patch fixes the issue for all the applicable modules. The BUG has not made it yet to the OMAP errata list and it is applicable to OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps. By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces the OCP clock to be running and allow the counter value to be updated properly in the OCP clock domain. The bug is going to fixed in future OMAP versions. Reported-Tested-by: dave.long@linaro.org [dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer and helped to test this patch] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> --- arch/arm/mach-omap2/pm44xx.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..974f7ea 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -196,7 +196,7 @@ static void omap_default_idle(void) static int __init omap4_pm_init(void) { int ret; - struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm; + struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup; struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm; if (!cpu_is_omap44xx()) @@ -220,14 +220,19 @@ static int __init omap4_pm_init(void) * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as * expected. The hardware recommendation is to enable static * dependencies for these to avoid system lock ups or random crashes. + * The L4 wakeup depedency is added to workaround the OCP sync hardware + * BUG with 32K synctimer which lead to incorrect timer value read + * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which + * are part of L4 wakeup clockdomain. */ mpuss_clkdm = clkdm_lookup("mpuss_clkdm"); emif_clkdm = clkdm_lookup("l3_emif_clkdm"); l3_1_clkdm = clkdm_lookup("l3_1_clkdm"); l3_2_clkdm = clkdm_lookup("l3_2_clkdm"); l4_per_clkdm = clkdm_lookup("l4_per_clkdm"); + l4wkup = clkdm_lookup("l4_wkup_clkdm"); ducati_clkdm = clkdm_lookup("ducati_clkdm"); - if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) || (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) goto err2; @@ -235,6 +240,7 @@ static int __init omap4_pm_init(void) ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup); ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); if (ret) { -- 1.7.4.1 [-- Attachment #2: 0001-ARM-OMAP4-Workaround-the-OCP-synchronisation-issue-w.patch --] [-- Type: text/x-patch, Size: 3667 bytes --] >From 2edeebbd434627d1d0a9d96f6c5bda044a68fa70 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar <santosh.shilimkar@ti.com> Date: Mon, 12 Mar 2012 20:34:45 +0530 Subject: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. On OMAP4, recently a synchronisation bug is discovered by hardware team, which leads to incorrect timer value read from 32K sync timer IP when the IP is comming out of idle. The issue is due to the synchronization methodology used in the SYNCTIMER IP. The value of the counter register in 32kHz domain is synchronized to the OCP domain register only at count up event, and if the OCP clock is switched off, the OCP register gets out of synch until the first count up event after the clock is switched back -at the next falling edge of the 32kHz clock. Further investigation revealed that it applies to gptimer1 and watchdog timer2 as well which may run on 32KHz. This patch fixes the issue for all the applicable modules. The BUG has not made it yet to the OMAP errata list and it is applicable to OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps. By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces the OCP clock to be running and allow the counter value to be updated properly in the OCP clock domain. The bug is going to fixed in future OMAP versions. Reported-Tested-by: dave.long@linaro.org [dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer and helped to test this patch] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> --- arch/arm/mach-omap2/pm44xx.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..974f7ea 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -196,7 +196,7 @@ static void omap_default_idle(void) static int __init omap4_pm_init(void) { int ret; - struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm; + struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup; struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm; if (!cpu_is_omap44xx()) @@ -220,14 +220,19 @@ static int __init omap4_pm_init(void) * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as * expected. The hardware recommendation is to enable static * dependencies for these to avoid system lock ups or random crashes. + * The L4 wakeup depedency is added to workaround the OCP sync hardware + * BUG with 32K synctimer which lead to incorrect timer value read + * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which + * are part of L4 wakeup clockdomain. */ mpuss_clkdm = clkdm_lookup("mpuss_clkdm"); emif_clkdm = clkdm_lookup("l3_emif_clkdm"); l3_1_clkdm = clkdm_lookup("l3_1_clkdm"); l3_2_clkdm = clkdm_lookup("l3_2_clkdm"); l4_per_clkdm = clkdm_lookup("l4_per_clkdm"); + l4wkup = clkdm_lookup("l4_wkup_clkdm"); ducati_clkdm = clkdm_lookup("ducati_clkdm"); - if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) || (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm)) goto err2; @@ -235,6 +240,7 @@ static int __init omap4_pm_init(void) ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm); ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm); + ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup); ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm); ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm); if (ret) { -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. 2012-03-13 8:47 ` Santosh Shilimkar @ 2012-03-13 16:31 ` Kevin Hilman 2012-03-13 16:40 ` Shilimkar, Santosh 0 siblings, 1 reply; 5+ messages in thread From: Kevin Hilman @ 2012-03-13 16:31 UTC (permalink / raw) To: Santosh Shilimkar; +Cc: linux-omap, dave.long, linux-arm-kernel Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote: >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes: >> >>> On OMAP4, recently a synchronisation bug is discovered by hardware >>> team, which leads to incorrect timer value read from 32K sync timer >>> IP when the IP is comming out of idle. >>> >>> The issue is due to the synchronization methodology used in the SYNCTIMER IP. >>> The value of the counter register in 32kHz domain is synchronized to the OCP >>> domain register only at count up event, and if the OCP clock is switched off, >>> the OCP register gets out of synch until the first count up event after the >>> clock is switched back -at the next falling edge of the 32kHz clock. >>> >>> Further investigation revealed that it applies to gptimer1 and watchdog timer2 >>> as well which may run on 32KHz. This patch fixes the issue for all the >>> applicable modules. >> >> The changelog describes the problem ver well, but doesn't actually >> describe the fix (enable static dep.) Can you update the changelog do >> describe the fix, and why it fixes the problem. >> > Sure. Updated patch below. The idea is to ensure that synctimer is > syncronised before software does any reads on the counter. The BUG > will get fixed in future OMAP designs Thanks for the updated changelog. Since this doesn't qualify as a regression, queuing for v3.4 (branch: for_3.4/fixes/pm) Kevin ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. 2012-03-13 16:31 ` Kevin Hilman @ 2012-03-13 16:40 ` Shilimkar, Santosh 0 siblings, 0 replies; 5+ messages in thread From: Shilimkar, Santosh @ 2012-03-13 16:40 UTC (permalink / raw) To: Kevin Hilman; +Cc: linux-omap, dave.long, linux-arm-kernel On Tue, Mar 13, 2012 at 10:01 PM, Kevin Hilman <khilman@ti.com> wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote: >>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes: >>> >>>> On OMAP4, recently a synchronisation bug is discovered by hardware >>>> team, which leads to incorrect timer value read from 32K sync timer >>>> IP when the IP is comming out of idle. >>>> >>>> The issue is due to the synchronization methodology used in the SYNCTIMER IP. >>>> The value of the counter register in 32kHz domain is synchronized to the OCP >>>> domain register only at count up event, and if the OCP clock is switched off, >>>> the OCP register gets out of synch until the first count up event after the >>>> clock is switched back -at the next falling edge of the 32kHz clock. >>>> >>>> Further investigation revealed that it applies to gptimer1 and watchdog timer2 >>>> as well which may run on 32KHz. This patch fixes the issue for all the >>>> applicable modules. >>> >>> The changelog describes the problem ver well, but doesn't actually >>> describe the fix (enable static dep.) Can you update the changelog do >>> describe the fix, and why it fixes the problem. >>> >> Sure. Updated patch below. The idea is to ensure that synctimer is >> syncronised before software does any reads on the counter. The BUG >> will get fixed in future OMAP designs > > Thanks for the updated changelog. > > Since this doesn't qualify as a regression, queuing for v3.4 (branch: for_3.4/fixes/pm) > Thanks Kevin. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-03-13 16:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-12 15:33 [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer Santosh Shilimkar 2012-03-12 16:51 ` Kevin Hilman 2012-03-13 8:47 ` Santosh Shilimkar 2012-03-13 16:31 ` Kevin Hilman 2012-03-13 16:40 ` Shilimkar, Santosh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox