[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[Paul Walmsley]

From: Rajendra Nayak <rnayak@ti.com>

Some issues seen (which cause lockups in suspend) with GPT1
after the MPU<->L4_WKUP static dependency was cleared can be
Worked-around for now by forcing GPT1 in software
controlled idle.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Beno?t Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7b72316..cfe957a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4005,6 +4005,7 @@ static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
 static struct omap_hwmod omap44xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
+	.flags		= HWMOD_SWSUP_SIDLE,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
 	.main_clk	= "timer1_fck",
-- 
1.7.2.3

[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[Paul Walmsley]

On Wed, 9 Mar 2011, Paul Walmsley wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> Some issues seen (which cause lockups in suspend) with GPT1
> after the MPU<->L4_WKUP static dependency was cleared can be
> Worked-around for now by forcing GPT1 in software
> controlled idle.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Beno?t Cousson <b-cousson@ti.com>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

Just a quick note, I missed Beno?t's update of the commit message:

    http://www.spinics.net/linux/lists/linux-omap/msg48008.html

and he's the maintainer of this so we should use his instead.  The revised 
message is below.


- Paul

OMAP4: hwmod data: Temporarily disable hardware-controlled idle for timer1
    
Some issues seen (which cause lockups in suspend) with timer1
after the MPU<->L4_WKUP static dependency was cleared can be
Worked-around for now by forcing timer1 in software
controlled idle.
    
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[b-cousson: Update the changelog and the subject]
Signed-off-by: Beno?t Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[Santosh Shilimkar]

Paul, Benoit,

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Thursday, March 10, 2011 2:15 PM
> To: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: Rajendra Nayak; Beno?t Cousson
> Subject: Re: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle
> for GPT1
>
> On Wed, 9 Mar 2011, Paul Walmsley wrote:
>
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Some issues seen (which cause lockups in suspend) with GPT1
> > after the MPU<->L4_WKUP static dependency was cleared can be
> > Worked-around for now by forcing GPT1 in software
> > controlled idle.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Beno?t Cousson <b-cousson@ti.com>
> > Signed-off-by: Paul Walmsley <paul@pwsan.com>
>
> Just a quick note, I missed Beno?t's update of the commit message:
>
>     http://www.spinics.net/linux/lists/linux-omap/msg48008.html
>
> and he's the maintainer of this so we should use his instead.  The
> revised
> message is below.
>

We continued further debug on the static dependency issues with
OMAP4 PM series.
So far from the findings what I have, this timer patch is actually not
needed and can be dropped. Infact the patch is not really effective
because current timer driver(not hwmod adapted yet) puts timer1
in smart idle again.

There is another static dep. just like MPUSS<-->EMIF seems to create
an issue. The lock-up is not very consistently reproducible so it's
very easy to get miss-leading results. Timer patch was one of those
observations. With or without timer patch I can reproduce the hang
with long duration test.

Will keep narrowing down the next offending static dependency but
in mean time I suggest you to drop this patch.

Regards,
Santosh

[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[Paul Walmsley]

On Thu, 10 Mar 2011, Santosh Shilimkar wrote:

> We continued further debug on the static dependency issues with
> OMAP4 PM series.
> So far from the findings what I have, this timer patch is actually not
> needed and can be dropped. Infact the patch is not really effective
> because current timer driver(not hwmod adapted yet) puts timer1
> in smart idle again.
> 
> There is another static dep. just like MPUSS<-->EMIF seems to create
> an issue. The lock-up is not very consistently reproducible so it's
> very easy to get miss-leading results. Timer patch was one of those
> observations. With or without timer patch I can reproduce the hang
> with long duration test.
> 
> Will keep narrowing down the next offending static dependency but
> in mean time I suggest you to drop this patch.

Okay, dropped.


- Paul

[PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

[Santosh Shilimkar]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Thursday, March 10, 2011 8:15 PM
> To: Santosh Shilimkar
> Cc: Benoit Cousson; Rajendra Nayak; linux-omap at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; Kevin Hilman
> Subject: RE: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle
> for GPT1
>
> On Thu, 10 Mar 2011, Santosh Shilimkar wrote:
>
> > We continued further debug on the static dependency issues with
> > OMAP4 PM series.
> > So far from the findings what I have, this timer patch is actually
> not
> > needed and can be dropped. Infact the patch is not really
> effective
> > because current timer driver(not hwmod adapted yet) puts timer1
> > in smart idle again.
> >
> > There is another static dep. just like MPUSS<-->EMIF seems to
> create
> > an issue. The lock-up is not very consistently reproducible so
> it's
> > very easy to get miss-leading results. Timer patch was one of
> those
> > observations. With or without timer patch I can reproduce the hang
> > with long duration test.
> >
> > Will keep narrowing down the next offending static dependency but
> > in mean time I suggest you to drop this patch.
>
> Okay, dropped.
>
Managed to narrow down the issue with below two offender.
1) MPUSS <--> MEMIF_STATDEP
2) MPUSS <--> L3_1_STATDEP

If we keep both of these static deps, then I don't see any
issues. Will give a overnight run to check the stability.

Will update the below patch to include L3_1 CD and
repost the same.
https://patchwork.kernel.org/patch/620351/

Regards
Santosh