OMAP4: hwmod: Disable hardware-controlled idle for GPT1

PATCH New Paul Walmsley 2 participants 5 messages Mar 10, 2011

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP hwmod data

lore

Share & tools

lore

Paul Walmsley

author maintainer

2011-03-10 01:48 UTC #0 lore raw

PATCH 1/1 OMAP4: hwmod: Disable hardware-controlled idle for GPT1

From: Rajendra Nayak <[email protected]>

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 <[email protected]>

Signed-off-by Beno?t Cousson <[email protected]>

Signed-off-by Paul Walmsley <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0

index 7b72316..cfe957a 100644
@@ -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",

Signature · 1 line

1.7.2.3

Paul Walmsley

author maintainer

2011-03-10 08:45 UTC #1 lore raw

PATCH 1/1 OMAP4: hwmod: Disable hardware-controlled idle for GPT1

Quoted 10 lines · Paul Walmsley

From: Rajendra Nayak <[email protected]>
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 <[email protected]>
Signed-off-by Beno?t Cousson <[email protected]>
Signed-off-by Paul Walmsley <[email protected]>

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 <[email protected]>

[b-cousson: Update the changelog and the subject]

Signed-off-by Beno?t Cousson <[email protected]>

Signed-off-by Paul Walmsley <[email protected]>

Santosh Shilimkar

2011-03-10 14:37 UTC #2 lore raw

PATCH 1/1 OMAP4: hwmod: Disable hardware-controlled idle for GPT1

Paul, Benoit,

Quoted 22 lines

-----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
Quoted 10 lines · Paul Walmsley
From: Rajendra Nayak <[email protected]>
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 <[email protected]>
Signed-off-by Beno?t Cousson <[email protected]>
Signed-off-by Paul Walmsley <[email protected]>

Quoted 8 lines

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

Paul Walmsley

author maintainer

2011-03-10 14:45 UTC #3 lore raw

PATCH 1/1 OMAP4: hwmod: Disable hardware-controlled idle for GPT1

Quoted 7 lines · Santosh Shilimkar

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.

Quoted 8 lines

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

Santosh Shilimkar

2011-03-10 16:27 UTC #4 lore raw

PATCH 1/1 OMAP4: hwmod: Disable hardware-controlled idle for GPT1

Quoted 25 lines

-----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
Quoted 3 lines · Santosh Shilimkar
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
Quoted 1 line
needed and can be dropped. Infact the patch is not really
effective
Quoted 4 lines
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
Quoted 1 line
an issue. The lock-up is not very consistently reproducible so
it's
Quoted 1 line
very easy to get miss-leading results. Timer patch was one of

Quoted 9 lines

those
Quoted 5 lines
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