Integration branch base switchover to Tony's omap-for-linus branch

Integration branch base switchover to Tony's omap-for-linus branch

[Paul Walmsley]

Hi,

this is a quick note for anyone using the integration-2.6.39 branch on 
git://git.pwsan.com/linux-2.6: I've switched the base over from 
mainline to Tony's omap-for-linus branch.


- Paul

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Santosh Shilimkar]

Pual,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Saturday, February 26, 2011 5:56 AM
> To: linux-omap@vger.kernel.org
> Subject: Integration branch base switchover to Tony's omap-for-linus
> branch
>
>
> Hi,
>
> this is a quick note for anyone using the integration-2.6.39 branch
> on
> git://git.pwsan.com/linux-2.6: I've switched the base over from
> mainline to Tony's omap-for-linus branch.
>

I observed an issue when integrated omap-for-linus + your branch
+ OMAP4 PM patches. After debugging this with Rajendra, it seems
that issue is seen only when static dependency between MPU
and L4PER clock-domain is cleared _and_ L4_PER clock-domain
is programmed to HW_SUP.

Since the issue is observed with only I2C IP block from L4_PER
and none of the other modules are affected, the suspect is I2C
IP block. The hardware team is investigating this issue.

So for now, to avoid this abort, there are two options
	- Remove HW_SUP from L4_PER CD
	- Keep MPU<->L4_PER static dependency.

We tried both the options and they seems to work.
Which one you prefer till we have hardware root-cause
of this issue?

Regards,
Santosh

----
Power Management for TI OMAP4.
clock: disabling unused clocks to save power
omap_device: omap_i2c.1: new worst case activate latency 0: 3143310
Unhandled fault: imprecise external abort (0x1406) at 0x3df31eef
Internal error: : 1406 [#1] SMP
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.38-rc6-00023-g0752c56-dirty #280)
PC is at omap_i2c_xfer+0x28/0x320
LR is at omap_i2c_wait_for_bb+0x18/0x7c
pc : [<c031e0dc>]    lr : [<c031d9b8>]    psr: 40000013
sp : ef833f08  ip : 000038ae  fp : c05e1906
r10: 00000002  r9 : ef9d1cb0  r8 : 00000002
r7 : ef9d1c00  r6 : ffff6b4b  r5 : 00000000  r4 : c0b44b9c
r3 : 0000001f  r2 : 00000028  r1 : 83126e98  r0 : 00000000
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 8000404a  DAC: 00000015
Process swapper (pid: 1, stack limit = 0xef8322f8)
Stack: (0xef833f08 to 0xef834000)
3f00:                   ef9d1c60 c0b44b9c 00000002 ef9d1c60 00000000
ffff6b4b
3f20: c0b44b9c 00000002 00000001 00000000 c05e1906 c031c25c ef9d1800
00000000
3f40: c0b44bb4 c0b44b94 c0b44b90 00000000 c0b44b94 c0299784 0000005c
ef833f97
3f60: efa9d874 8c000013 efa9d874 efa9d800 efa9d870 c05dc73c 00000000
00000000
3f80: 00000000 00000000 00000000 c02658d0 efa9d800 22222222 ffffffd0
c0265984
3fa0: efa9d800 c00260ac c00334dc c0026034 00000002 c00505cc 00000000
c0160000
3fc0: c04f4a05 00000198 c0594350 c00334dc c0594350 00000002 00000013
00000000
3fe0: 00000000 c0008540 00000000 c00083f4 c005b520 c005b520 e72105ac
04088b22
[<c031e0dc>] (omap_i2c_xfer+0x28/0x320) from [<c031c25c>]
(i2c_transfer+0xbc/0x10c)
[<c031c25c>] (i2c_transfer+0xbc/0x10c) from [<c0299784>]
(twl_i2c_read+0xe0/0x12c)
[<c0299784>] (twl_i2c_read+0xe0/0x12c) from [<c02658d0>]
(twlreg_grp+0x18/0x24)
[<c02658d0>] (twlreg_grp+0x18/0x24) from [<c0265984>]
(twlreg_is_enabled+0x8/0x30)
[<c0265984>] (twlreg_is_enabled+0x8/0x30) from [<c00260ac>]
(regulator_init_complete+0x78/0x148)
[<c00260ac>] (regulator_init_complete+0x78/0x148) from [<c00505cc>]
(do_one_initcall+0xcc/0x1a4)
[<c00505cc>] (do_one_initcall+0xcc/0x1a4) from [<c0008540>]
(kernel_init+0x14c/0x214)
[<c0008540>] (kernel_init+0x14c/0x214) from [<c005b520>]
(kernel_thread_exit+0x0/0x8)
Code: e1a07000 ebfffe51 e1a00007 ebfffe30 (e2506000)
---[ end trace ccd8ab0702d3ee85 ]---

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Paul Walmsley]

Hi Santosh

On Tue, 1 Mar 2011, Santosh Shilimkar wrote:

> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Paul Walmsley
> > Sent: Saturday, February 26, 2011 5:56 AM
> > To: linux-omap@vger.kernel.org
> > Subject: Integration branch base switchover to Tony's omap-for-linus
> > branch
> >
> >
> > Hi,
> >
> > this is a quick note for anyone using the integration-2.6.39 branch
> > on
> > git://git.pwsan.com/linux-2.6: I've switched the base over from
> > mainline to Tony's omap-for-linus branch.
> >
> 
> I observed an issue when integrated omap-for-linus + your branch
> + OMAP4 PM patches. After debugging this with Rajendra, it seems
> that issue is seen only when static dependency between MPU
> and L4PER clock-domain is cleared _and_ L4_PER clock-domain
> is programmed to HW_SUP.
> 
> Since the issue is observed with only I2C IP block from L4_PER
> and none of the other modules are affected, the suspect is I2C
> IP block. The hardware team is investigating this issue.
> 
> So for now, to avoid this abort, there are two options
> 	- Remove HW_SUP from L4_PER CD
> 	- Keep MPU<->L4_PER static dependency.
> 
> We tried both the options and they seems to work.
> Which one you prefer till we have hardware root-cause
> of this issue?

Between the two alternatives you suggested, I'd prefer #1; but could you 
try forcing the I2C blocks to use software idle control instead and see if 
that fixes it without the need to change the clockdomains file?  Sample 
patch follows.  If that fixes it, it might be useful to know whether it is 
the HWMOD_SWSUP_SIDLE flag or HWMOD_NO_OCP_AUTOIDLE flag or both that is 
required.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 1 Mar 2011 14:11:31 -0700
Subject: [PATCH] OMAP4: I2C hwmods: Test patch to attempt to narrow down crashes

Put the I2C IP blocks into software-controlled idle to attempt to narrow down
some crashes.
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..8415b97 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2124,7 +2124,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] = {
 static struct omap_hwmod omap44xx_i2c1_hwmod = {
 	.name		= "i2c1",
 	.class		= &omap44xx_i2c_hwmod_class,
-	.flags		= HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
 	.mpu_irqs	= omap44xx_i2c1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c1_irqs),
 	.sdma_reqs	= omap44xx_i2c1_sdma_reqs,
@@ -2177,7 +2177,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] = {
 static struct omap_hwmod omap44xx_i2c2_hwmod = {
 	.name		= "i2c2",
 	.class		= &omap44xx_i2c_hwmod_class,
-	.flags		= HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
 	.mpu_irqs	= omap44xx_i2c2_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c2_irqs),
 	.sdma_reqs	= omap44xx_i2c2_sdma_reqs,
@@ -2230,7 +2230,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] = {
 static struct omap_hwmod omap44xx_i2c3_hwmod = {
 	.name		= "i2c3",
 	.class		= &omap44xx_i2c_hwmod_class,
-	.flags		= HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
 	.mpu_irqs	= omap44xx_i2c3_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c3_irqs),
 	.sdma_reqs	= omap44xx_i2c3_sdma_reqs,
@@ -2283,7 +2283,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c4_slaves[] = {
 static struct omap_hwmod omap44xx_i2c4_hwmod = {
 	.name		= "i2c4",
 	.class		= &omap44xx_i2c_hwmod_class,
-	.flags		= HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
 	.mpu_irqs	= omap44xx_i2c4_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c4_irqs),
 	.sdma_reqs	= omap44xx_i2c4_sdma_reqs,
-- 
1.7.2.3

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Rajendra Nayak]

Hi Paul,

On Wednesday 02 March 2011 03:03 AM, Paul Walmsley wrote:
> Hi Santosh
>
> On Tue, 1 Mar 2011, Santosh Shilimkar wrote:
>
>>> -----Original Message-----
>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>> owner@vger.kernel.org] On Behalf Of Paul Walmsley
>>> Sent: Saturday, February 26, 2011 5:56 AM
>>> To: linux-omap@vger.kernel.org
>>> Subject: Integration branch base switchover to Tony's omap-for-linus
>>> branch
>>>
>>>
>>> Hi,
>>>
>>> this is a quick note for anyone using the integration-2.6.39 branch
>>> on
>>> git://git.pwsan.com/linux-2.6: I've switched the base over from
>>> mainline to Tony's omap-for-linus branch.
>>>
>>
>> I observed an issue when integrated omap-for-linus + your branch
>> + OMAP4 PM patches. After debugging this with Rajendra, it seems
>> that issue is seen only when static dependency between MPU
>> and L4PER clock-domain is cleared _and_ L4_PER clock-domain
>> is programmed to HW_SUP.
>>
>> Since the issue is observed with only I2C IP block from L4_PER
>> and none of the other modules are affected, the suspect is I2C
>> IP block. The hardware team is investigating this issue.
>>
>> So for now, to avoid this abort, there are two options
>> 	- Remove HW_SUP from L4_PER CD
>> 	- Keep MPU<->L4_PER static dependency.
>>
>> We tried both the options and they seems to work.
>> Which one you prefer till we have hardware root-cause
>> of this issue?
>
> Between the two alternatives you suggested, I'd prefer #1; but could you
> try forcing the I2C blocks to use software idle control instead and see if
> that fixes it without the need to change the clockdomains file?  Sample
> patch follows.  If that fixes it, it might be useful to know whether it is
> the HWMOD_SWSUP_SIDLE flag or HWMOD_NO_OCP_AUTOIDLE flag or both that is
> required.

Yes, it does seem to fix the issue also, and its the HWMOD_SWSUP_SIDLE
that apparently makes a difference. HWMOD_NO_OCP_AUTOIDLE alone does
not fix it.

Also some more testing showed up a lockup in suspend on OMAP4 which I
could narrow down to a similar case with GPT1. Either keeping the
staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use software
idle control seems to help.

regards,
Rajendra

>
>
> - Paul
>
> From: Paul Walmsley<paul@pwsan.com>
> Date: Tue, 1 Mar 2011 14:11:31 -0700
> Subject: [PATCH] OMAP4: I2C hwmods: Test patch to attempt to narrow down crashes
>
> Put the I2C IP blocks into software-controlled idle to attempt to narrow down
> some crashes.
> ---
>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    8 ++++----
>   1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 79a8601..8415b97 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2124,7 +2124,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] = {
>   static struct omap_hwmod omap44xx_i2c1_hwmod = {
>   	.name		= "i2c1",
>   	.class		=&omap44xx_i2c_hwmod_class,
> -	.flags		= HWMOD_INIT_NO_RESET,
> +	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
>   	.mpu_irqs	= omap44xx_i2c1_irqs,
>   	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c1_irqs),
>   	.sdma_reqs	= omap44xx_i2c1_sdma_reqs,
> @@ -2177,7 +2177,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] = {
>   static struct omap_hwmod omap44xx_i2c2_hwmod = {
>   	.name		= "i2c2",
>   	.class		=&omap44xx_i2c_hwmod_class,
> -	.flags		= HWMOD_INIT_NO_RESET,
> +	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
>   	.mpu_irqs	= omap44xx_i2c2_irqs,
>   	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c2_irqs),
>   	.sdma_reqs	= omap44xx_i2c2_sdma_reqs,
> @@ -2230,7 +2230,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] = {
>   static struct omap_hwmod omap44xx_i2c3_hwmod = {
>   	.name		= "i2c3",
>   	.class		=&omap44xx_i2c_hwmod_class,
> -	.flags		= HWMOD_INIT_NO_RESET,
> +	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
>   	.mpu_irqs	= omap44xx_i2c3_irqs,
>   	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c3_irqs),
>   	.sdma_reqs	= omap44xx_i2c3_sdma_reqs,
> @@ -2283,7 +2283,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c4_slaves[] = {
>   static struct omap_hwmod omap44xx_i2c4_hwmod = {
>   	.name		= "i2c4",
>   	.class		=&omap44xx_i2c_hwmod_class,
> -	.flags		= HWMOD_INIT_NO_RESET,
> +	.flags		= HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE | HWMOD_NO_OCP_AUTOIDLE,
>   	.mpu_irqs	= omap44xx_i2c4_irqs,
>   	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_i2c4_irqs),
>   	.sdma_reqs	= omap44xx_i2c4_sdma_reqs,

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Rajendra Nayak]

[-- Attachment #1: Type: text/plain, Size: 6796 bytes --]

Hi Paul,

On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
> Hi Paul,
>
> On Wednesday 02 March 2011 03:03 AM, Paul Walmsley wrote:
>> Hi Santosh
>>
>> On Tue, 1 Mar 2011, Santosh Shilimkar wrote:
>>
>>>> -----Original Message-----
>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>>> owner@vger.kernel.org] On Behalf Of Paul Walmsley
>>>> Sent: Saturday, February 26, 2011 5:56 AM
>>>> To: linux-omap@vger.kernel.org
>>>> Subject: Integration branch base switchover to Tony's omap-for-linus
>>>> branch
>>>>
>>>>
>>>> Hi,
>>>>
>>>> this is a quick note for anyone using the integration-2.6.39 branch
>>>> on
>>>> git://git.pwsan.com/linux-2.6: I've switched the base over from
>>>> mainline to Tony's omap-for-linus branch.
>>>>
>>>
>>> I observed an issue when integrated omap-for-linus + your branch
>>> + OMAP4 PM patches. After debugging this with Rajendra, it seems
>>> that issue is seen only when static dependency between MPU
>>> and L4PER clock-domain is cleared _and_ L4_PER clock-domain
>>> is programmed to HW_SUP.
>>>
>>> Since the issue is observed with only I2C IP block from L4_PER
>>> and none of the other modules are affected, the suspect is I2C
>>> IP block. The hardware team is investigating this issue.
>>>
>>> So for now, to avoid this abort, there are two options
>>> - Remove HW_SUP from L4_PER CD
>>> - Keep MPU<->L4_PER static dependency.
>>>
>>> We tried both the options and they seems to work.
>>> Which one you prefer till we have hardware root-cause
>>> of this issue?
>>
>> Between the two alternatives you suggested, I'd prefer #1; but could you
>> try forcing the I2C blocks to use software idle control instead and
>> see if
>> that fixes it without the need to change the clockdomains file? Sample
>> patch follows. If that fixes it, it might be useful to know whether it is
>> the HWMOD_SWSUP_SIDLE flag or HWMOD_NO_OCP_AUTOIDLE flag or both that is
>> required.
>
> Yes, it does seem to fix the issue also, and its the HWMOD_SWSUP_SIDLE
> that apparently makes a difference. HWMOD_NO_OCP_AUTOIDLE alone does
> not fix it.

Some more debugging by the Hardware team and analyzing
the register dumps showed that the I2C_WE register of the i2c
modules needs to be programmed correctly for i2c wakeups to
function as expected.
This turned out to be the root cause for the i2c issues observed
by clearing the staticdeps and a patch has been posted
to address this...
http://marc.info/?l=linux-omap&m=129924557219813&w=2

>
> Also some more testing showed up a lockup in suspend on OMAP4 which I
> could narrow down to a similar case with GPT1. Either keeping the
> staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use software
> idle control seems to help.

This however is still not rootcaused and is not the same as the issue
seen with i2c as the WE for GPT1 is already programmed for enabling
wakeup.

The one way to fix this for now is to put GPT1 block in software
controlled idle as was done by your test patch for i2c.

---
 From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Fri, 4 Mar 2011 19:33:45 +0530
Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

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>
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2c58827..9317a05 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3989,7 +3989,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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+       .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET | 
HWMOD_SWSUP_SIDLE,
         .mpu_irqs       = omap44xx_timer1_irqs,
         .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_timer1_irqs),
         .main_clk       = "timer1_fck",
-- 
1.7.0.4

>
> regards,
> Rajendra
>
>>
>>
>> - Paul
>>
>> From: Paul Walmsley<paul@pwsan.com>
>> Date: Tue, 1 Mar 2011 14:11:31 -0700
>> Subject: [PATCH] OMAP4: I2C hwmods: Test patch to attempt to narrow
>> down crashes
>>
>> Put the I2C IP blocks into software-controlled idle to attempt to
>> narrow down
>> some crashes.
>> ---
>> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> index 79a8601..8415b97 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> @@ -2124,7 +2124,7 @@ static struct omap_hwmod_ocp_if
>> *omap44xx_i2c1_slaves[] = {
>> static struct omap_hwmod omap44xx_i2c1_hwmod = {
>> .name = "i2c1",
>> .class =&omap44xx_i2c_hwmod_class,
>> - .flags = HWMOD_INIT_NO_RESET,
>> + .flags = HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE |
>> HWMOD_NO_OCP_AUTOIDLE,
>> .mpu_irqs = omap44xx_i2c1_irqs,
>> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c1_irqs),
>> .sdma_reqs = omap44xx_i2c1_sdma_reqs,
>> @@ -2177,7 +2177,7 @@ static struct omap_hwmod_ocp_if
>> *omap44xx_i2c2_slaves[] = {
>> static struct omap_hwmod omap44xx_i2c2_hwmod = {
>> .name = "i2c2",
>> .class =&omap44xx_i2c_hwmod_class,
>> - .flags = HWMOD_INIT_NO_RESET,
>> + .flags = HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE |
>> HWMOD_NO_OCP_AUTOIDLE,
>> .mpu_irqs = omap44xx_i2c2_irqs,
>> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c2_irqs),
>> .sdma_reqs = omap44xx_i2c2_sdma_reqs,
>> @@ -2230,7 +2230,7 @@ static struct omap_hwmod_ocp_if
>> *omap44xx_i2c3_slaves[] = {
>> static struct omap_hwmod omap44xx_i2c3_hwmod = {
>> .name = "i2c3",
>> .class =&omap44xx_i2c_hwmod_class,
>> - .flags = HWMOD_INIT_NO_RESET,
>> + .flags = HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE |
>> HWMOD_NO_OCP_AUTOIDLE,
>> .mpu_irqs = omap44xx_i2c3_irqs,
>> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c3_irqs),
>> .sdma_reqs = omap44xx_i2c3_sdma_reqs,
>> @@ -2283,7 +2283,7 @@ static struct omap_hwmod_ocp_if
>> *omap44xx_i2c4_slaves[] = {
>> static struct omap_hwmod omap44xx_i2c4_hwmod = {
>> .name = "i2c4",
>> .class =&omap44xx_i2c_hwmod_class,
>> - .flags = HWMOD_INIT_NO_RESET,
>> + .flags = HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE |
>> HWMOD_NO_OCP_AUTOIDLE,
>> .mpu_irqs = omap44xx_i2c4_irqs,
>> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c4_irqs),
>> .sdma_reqs = omap44xx_i2c4_sdma_reqs,
>


[-- Attachment #2: 0001-OMAP4-hwmod-Disable-hardware-controlled-idle-for-GPT.patch --]
[-- Type: text/x-patch, Size: 1252 bytes --]

>From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Fri, 4 Mar 2011 19:33:45 +0530
Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

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>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2c58827..9317a05 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3989,7 +3989,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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET | HWMOD_SWSUP_SIDLE,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
 	.main_clk	= "timer1_fck",
-- 
1.7.0.4

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Cousson, Benoit]

Hi Rajendra,

On 3/4/2011 3:08 PM, Nayak, Rajendra wrote:
> Hi Paul,

[...]

> This however is still not rootcaused and is not the same as the issue
> seen with i2c as the WE for GPT1 is already programmed for enabling
> wakeup.
>
> The one way to fix this for now is to put GPT1 block in software
> controlled idle as was done by your test patch for i2c.
>
> ---
>   From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak<rnayak@ti.com>
> Date: Fri, 4 Mar 2011 19:33:45 +0530
> Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1

Maybe we should emphasis the temporary need for this commit to avoid 
forgetting it?

> 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>
> ---
>    arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
>    1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 2c58827..9317a05 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,7 +3989,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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> +       .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
> HWMOD_SWSUP_SIDLE,

I was wondering why the previous flags were still there, but it looks 
like the revert was not done.

I'll push it with the revert for the flags.

Where is the Santosh's branch that should be rebased on top of that one?

Benoit

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Santosh Shilimkar]

> -----Original Message-----
> From: Cousson, Benoit [mailto:b-cousson@ti.com]
> Sent: Friday, March 04, 2011 8:29 PM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Shilimkar, Santosh; linux-omap@vger.kernel.org
> Subject: Re: Integration branch base switchover to Tony's omap-for-
> linus branch
>
> Hi Rajendra,
>
> On 3/4/2011 3:08 PM, Nayak, Rajendra wrote:
> > Hi Paul,
>
> [...]
>
> > This however is still not rootcaused and is not the same as the
> issue
> > seen with i2c as the WE for GPT1 is already programmed for
> enabling
> > wakeup.
> >
> > The one way to fix this for now is to put GPT1 block in software
> > controlled idle as was done by your test patch for i2c.
> >
> > ---
> >   From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17
> 00:00:00 2001
> > From: Rajendra Nayak<rnayak@ti.com>
> > Date: Fri, 4 Mar 2011 19:33:45 +0530
> > Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle
> for GPT1
>
> Maybe we should emphasis the temporary need for this commit to avoid
> forgetting it?
>
> > 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>
> > ---
> >    arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
> >    1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > index 2c58827..9317a05 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -3989,7 +3989,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_INIT_NO_IDLE |
> HWMOD_INIT_NO_RESET,
> > +       .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET
> |
> > HWMOD_SWSUP_SIDLE,
>
> I was wondering why the previous flags were still there, but it
> looks
> like the revert was not done.
>
> I'll push it with the revert for the flags.
>
> Where is the Santosh's branch that should be rebased on top of that
> one?
>
I am trying to rebase it on Kevin's pm-core branch. Will cherry pick
these patches

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Cousson, Benoit]

On 3/4/2011 4:01 PM, Shilimkar, Santosh wrote:
>> From: Cousson, Benoit [mailto:b-cousson@ti.com]
>> Sent: Friday, March 04, 2011 8:29 PM
>>
>> Hi Rajendra,
>>
>> On 3/4/2011 3:08 PM, Nayak, Rajendra wrote:
>>> Hi Paul,
>>
>> [...]
>>
>>> This however is still not rootcaused and is not the same as the
>> issue
>>> seen with i2c as the WE for GPT1 is already programmed for
>> enabling
>>> wakeup.
>>>
>>> The one way to fix this for now is to put GPT1 block in software
>>> controlled idle as was done by your test patch for i2c.
>>>
>>> ---
>>>    From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17
>> 00:00:00 2001
>>> From: Rajendra Nayak<rnayak@ti.com>
>>> Date: Fri, 4 Mar 2011 19:33:45 +0530
>>> Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle
>> for GPT1
>>
>> Maybe we should emphasis the temporary need for this commit to avoid
>> forgetting it?
>>
>>> 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>
>>> ---
>>>     arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
>>>     1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> index 2c58827..9317a05 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> @@ -3989,7 +3989,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_INIT_NO_IDLE |
>> HWMOD_INIT_NO_RESET,
>>> +       .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET
>> |
>>> HWMOD_SWSUP_SIDLE,
>>
>> I was wondering why the previous flags were still there, but it
>> looks
>> like the revert was not done.
>>
>> I'll push it with the revert for the flags.
>>
>> Where is the Santosh's branch that should be rebased on top of that
>> one?
>>
> I am trying to rebase it on Kevin's pm-core branch. Will cherry pick
> these patches

Cool, I updated Rajendra's patch and rebased it on top of the revert.
Both patches are below.

You can find them in the following place:
git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data_fixes

Could you check them before I can send a pull request to Tony?

Thanks,
Benoit

---
 From aa22c44486c12c388eb96e9fe9b1476267856006 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 4 Mar 2011 16:01:43 +0100
Subject: [PATCH 1/2] Revert "OMAP4: hwmod data: Prevent timer1 to be 
reset and idle during init"

The following commit: 38698be:
OMAP2+: clockevent: set up GPTIMER clockevent hwmod right before timer init

Fixed properly the issue with early init for the timer1

So reverts commit 3b03b58dab847883e6b9a431558c7d8e43fa94c6 that is now
generated a warning at boot time.

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7dbcdf7..7b72316 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4005,7 +4005,6 @@ 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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
  	.mpu_irqs	= omap44xx_timer1_irqs,
  	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
  	.main_clk	= "timer1_fck",
-- 
1.7.0.4

---
 From cdaaad0d1ce032129102b6ebc56e372d6f345861 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Fri, 4 Mar 2011 19:33:45 +0530
Subject: [PATCH 2/2] OMAP4: hwmod data: Temporary 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: Benoit Cousson <b-cousson@ti.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.0.4

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Santosh Shilimkar]

[-- Attachment #1: Type: text/plain, Size: 4721 bytes --]

Rajendra,

> -----Original Message-----
> From: Rajendra Nayak [mailto:rnayak@ti.com]
> Sent: Friday, March 04, 2011 7:38 PM
> To: Paul Walmsley
> Cc: Santosh Shilimkar; linux-omap@vger.kernel.org
> Subject: Re: Integration branch base switchover to Tony's omap-for-
> linus branch
>
> Hi Paul,
>
> On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
> > Hi Paul,
> >
> > On Wednesday 02 March 2011 03:03 AM, Paul Walmsley wrote:
> >> Hi Santosh
> >>
> >> On Tue, 1 Mar 2011, Santosh Shilimkar wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >>>> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> >>>> Sent: Saturday, February 26, 2011 5:56 AM
> >>>> To: linux-omap@vger.kernel.org
> >>>> Subject: Integration branch base switchover to Tony's omap-for-
> linus
> >>>> branch
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> this is a quick note for anyone using the integration-2.6.39
> branch
> >>>> on
> >>>> git://git.pwsan.com/linux-2.6: I've switched the base over from
> >>>> mainline to Tony's omap-for-linus branch.
> >>>>
> >>>
> >>> I observed an issue when integrated omap-for-linus + your branch
> >>> + OMAP4 PM patches. After debugging this with Rajendra, it seems
> >>> that issue is seen only when static dependency between MPU
> >>> and L4PER clock-domain is cleared _and_ L4_PER clock-domain
> >>> is programmed to HW_SUP.
> >>>
> >>> Since the issue is observed with only I2C IP block from L4_PER
> >>> and none of the other modules are affected, the suspect is I2C
> >>> IP block. The hardware team is investigating this issue.
> >>>
> >>> So for now, to avoid this abort, there are two options
> >>> - Remove HW_SUP from L4_PER CD
> >>> - Keep MPU<->L4_PER static dependency.
> >>>
> >>> We tried both the options and they seems to work.
> >>> Which one you prefer till we have hardware root-cause
> >>> of this issue?
> >>
> >> Between the two alternatives you suggested, I'd prefer #1; but
> could you
> >> try forcing the I2C blocks to use software idle control instead
> and
> >> see if
> >> that fixes it without the need to change the clockdomains file?
> Sample
> >> patch follows. If that fixes it, it might be useful to know
> whether it is
> >> the HWMOD_SWSUP_SIDLE flag or HWMOD_NO_OCP_AUTOIDLE flag or both
> that is
> >> required.
> >
> > Yes, it does seem to fix the issue also, and its the
> HWMOD_SWSUP_SIDLE
> > that apparently makes a difference. HWMOD_NO_OCP_AUTOIDLE alone
> does
> > not fix it.
>
> Some more debugging by the Hardware team and analyzing
> the register dumps showed that the I2C_WE register of the i2c
> modules needs to be programmed correctly for i2c wakeups to
> function as expected.
> This turned out to be the root cause for the i2c issues observed
> by clearing the staticdeps and a patch has been posted
> to address this...
> http://marc.info/?l=linux-omap&m=129924557219813&w=2
>
> >
> > Also some more testing showed up a lockup in suspend on OMAP4
> which I
> > could narrow down to a similar case with GPT1. Either keeping the
> > staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use
> software
> > idle control seems to help.
>
> This however is still not rootcaused and is not the same as the
> issue
> seen with i2c as the WE for GPT1 is already programmed for enabling
> wakeup.
>
> The one way to fix this for now is to put GPT1 block in software
> controlled idle as was done by your test patch for i2c.
>
I tried all the floating patches for static dependency. It did
worked when CPU RET was tried but with MPU OFF I see the hang.

Below is the global hack I have which works as expected for
all cases.

---
>From cd14eb718a7e909e32a5d1916517ae76312f0557 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 3 Mar 2011 15:10:07 +0530
Subject: [PATCH] omap4: static-deps: Temporary hack to disable mpu
wakupdeps

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index a607ec1..3c89bcc 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -281,6 +281,7 @@ static struct clkdm_dep l4_secure_wkup_sleep_deps[] =
{
 };

 static struct clkdm_dep mpuss_wkup_sleep_deps[] = {
+#if 0
 	{
 		.clkdm_name	 = "abe_clkdm",
 		.omap_chip	 = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
@@ -337,6 +338,7 @@ static struct clkdm_dep mpuss_wkup_sleep_deps[] = {
 		.clkdm_name	 = "tesla_clkdm",
 		.omap_chip	 = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
 	},
+#endif
 	{ NULL },
 };

-- 
1.6.0.4

[-- Attachment #2: 0001-omap4-static-deps-Temporary-hack-to-disable-mpu-wa.patch --]
[-- Type: application/octet-stream, Size: 1066 bytes --]

From cd14eb718a7e909e32a5d1916517ae76312f0557 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 3 Mar 2011 15:10:07 +0530
Subject: [PATCH] omap4: static-deps: Temporary hack to disable mpu wakupdeps

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index a607ec1..3c89bcc 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -281,6 +281,7 @@ static struct clkdm_dep l4_secure_wkup_sleep_deps[] = {
 };
 
 static struct clkdm_dep mpuss_wkup_sleep_deps[] = {
+#if 0
 	{
 		.clkdm_name	 = "abe_clkdm",
 		.omap_chip	 = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
@@ -337,6 +338,7 @@ static struct clkdm_dep mpuss_wkup_sleep_deps[] = {
 		.clkdm_name	 = "tesla_clkdm",
 		.omap_chip	 = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
 	},
+#endif
 	{ NULL },
 };
 
-- 
1.6.0.4

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2320 bytes --]

Hi Rajendra, Santosh,

On Fri, 4 Mar 2011, Rajendra Nayak wrote:

> On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
>  
> > Also some more testing showed up a lockup in suspend on OMAP4 which I
> > could narrow down to a similar case with GPT1. Either keeping the
> > staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use software
> > idle control seems to help.
> 
> This however is still not rootcaused and is not the same as the issue
> seen with i2c as the WE for GPT1 is already programmed for enabling
> wakeup.
> 
> The one way to fix this for now is to put GPT1 block in software
> controlled idle as was done by your test patch for i2c.

OK, thanks for the update.

Benoît, do you have any more OMAP4 hwmod patches for 2.6.39?  If not, want 
to send an Acked-by:, and either Tony or I will take this one?


- Paul

> ---
> From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak@ti.com>
> Date: Fri, 4 Mar 2011 19:33:45 +0530
> Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1
> 
> 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>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 2c58827..9317a05 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,7 +3989,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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> +       .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
> HWMOD_SWSUP_SIDLE,
>         .mpu_irqs       = omap44xx_timer1_irqs,
>         .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_timer1_irqs),
>         .main_clk       = "timer1_fck",
> -- 
> 1.7.0.4


- Paul

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Cousson, Benoit]

Salut Paul,

On 3/8/2011 12:25 AM, Paul Walmsley wrote:
> Hi Rajendra, Santosh,
>
> On Fri, 4 Mar 2011, Rajendra Nayak wrote:
>
>> On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
>>
>>> Also some more testing showed up a lockup in suspend on OMAP4 which I
>>> could narrow down to a similar case with GPT1. Either keeping the
>>> staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use software
>>> idle control seems to help.
>>
>> This however is still not rootcaused and is not the same as the issue
>> seen with i2c as the WE for GPT1 is already programmed for enabling
>> wakeup.
>>
>> The one way to fix this for now is to put GPT1 block in software
>> controlled idle as was done by your test patch for i2c.
>
> OK, thanks for the update.
>
> Benoît, do you have any more OMAP4 hwmod patches for 2.6.39?  If not, want
> to send an Acked-by:, and either Tony or I will take this one?

I already slightly modified this one and added it with the revert patch 
last Friday. It was in the reply to this email.

I was hoping for a definitive fix instead of a temporary one :-(

You can find them in the following place:
git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data_fixes

Regards
Benoit

---
 From aa22c44486c12c388eb96e9fe9b1476267856006 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 4 Mar 2011 16:01:43 +0100
Subject: [PATCH 1/2] Revert "OMAP4: hwmod data: Prevent timer1 to be
reset and idle during init"

The following commit: 38698be:
OMAP2+: clockevent: set up GPTIMER clockevent hwmod right before timer init

Fixed properly the issue with early init for the timer1

So reverts commit 3b03b58dab847883e6b9a431558c7d8e43fa94c6 that is now
generated a warning at boot time.

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7dbcdf7..7b72316 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4005,7 +4005,6 @@ 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_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
   	.mpu_irqs	= omap44xx_timer1_irqs,
   	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
   	.main_clk	= "timer1_fck",
--
1.7.0.4


---
 From cdaaad0d1ce032129102b6ebc56e372d6f345861 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Fri, 4 Mar 2011 19:33:45 +0530
Subject: [PATCH 2/2] OMAP4: hwmod data: Temporary 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: Benoit Cousson <b-cousson@ti.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.0.4
--
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

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Santosh Shilimkar]

Paul,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, March 04, 2011 10:14 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org; Benoit Cousson; Paul Walmsley
> Subject: RE: Integration branch base switchover to Tony's omap-for-
> linus branch
>

 [....]

> > Some more debugging by the Hardware team and analyzing
> > the register dumps showed that the I2C_WE register of the i2c
> > modules needs to be programmed correctly for i2c wakeups to
> > function as expected.
> > This turned out to be the root cause for the i2c issues observed
> > by clearing the staticdeps and a patch has been posted
> > to address this...
> > http://marc.info/?l=linux-omap&m=129924557219813&w=2
> >
> > >
> > > Also some more testing showed up a lockup in suspend on OMAP4
> > which I
> > > could narrow down to a similar case with GPT1. Either keeping
> the
> > > staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use
> > software
> > > idle control seems to help.
> >
> > This however is still not rootcaused and is not the same as the
> > issue
> > seen with i2c as the WE for GPT1 is already programmed for
> enabling
> > wakeup.
> >
> > The one way to fix this for now is to put GPT1 block in software
> > controlled idle as was done by your test patch for i2c.
> >
> I tried all the floating patches for static dependency. It did
> worked when CPU RET was tried but with MPU OFF I see the hang.
>
> Below is the global hack I have which works as expected for
> all cases.
>
Thanks to Rajendra for isolating the OMAP4 MPU OFF issue
with static dependency series. The issue is isolated
to MPU <-> EMIF clock dependency.  There issue appears
if we clear this static dependency.

I have posted a patch to work-around this issue till its
being root-caused with help of hardware team so that
OMAP4 PM series continue to work.

'OMAP4: PM: Set static dependency between MPUSS and EMIF'
http://www.listware.net/201103/linux-omap/2628-patch-omap4-pm-set-static-d
ependency-between-mpuss-and-emif.html


Regards,
Santosh

Re: Integration branch base switchover to Tony's omap-for-linus branch

[Cousson, Benoit]

On 3/8/2011 4:16 PM, Shilimkar, Santosh wrote:
> Paul,
>> -----Original Message-----
>> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
>> Sent: Friday, March 04, 2011 10:14 PM
>> To: Rajendra Nayak
>> Cc: linux-omap@vger.kernel.org; Benoit Cousson; Paul Walmsley
>> Subject: RE: Integration branch base switchover to Tony's omap-for-
>> linus branch
>>
>
>   [....]
>
>>> Some more debugging by the Hardware team and analyzing
>>> the register dumps showed that the I2C_WE register of the i2c
>>> modules needs to be programmed correctly for i2c wakeups to
>>> function as expected.
>>> This turned out to be the root cause for the i2c issues observed
>>> by clearing the staticdeps and a patch has been posted
>>> to address this...
>>> http://marc.info/?l=linux-omap&m=129924557219813&w=2
>>>
>>>>
>>>> Also some more testing showed up a lockup in suspend on OMAP4
>>> which I
>>>> could narrow down to a similar case with GPT1. Either keeping
>> the
>>>> staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use
>>> software
>>>> idle control seems to help.
>>>
>>> This however is still not rootcaused and is not the same as the
>>> issue
>>> seen with i2c as the WE for GPT1 is already programmed for
>> enabling
>>> wakeup.
>>>
>>> The one way to fix this for now is to put GPT1 block in software
>>> controlled idle as was done by your test patch for i2c.
>>>
>> I tried all the floating patches for static dependency. It did
>> worked when CPU RET was tried but with MPU OFF I see the hang.
>>
>> Below is the global hack I have which works as expected for
>> all cases.
>>
> Thanks to Rajendra for isolating the OMAP4 MPU OFF issue
> with static dependency series. The issue is isolated
> to MPU<->  EMIF clock dependency.  There issue appears
> if we clear this static dependency.
>
> I have posted a patch to work-around this issue till its
> being root-caused with help of hardware team so that
> OMAP4 PM series continue to work.
>
> 'OMAP4: PM: Set static dependency between MPUSS and EMIF'
> http://www.listware.net/201103/linux-omap/2628-patch-omap4-pm-set-static-d
> ependency-between-mpuss-and-emif.html

Cool, so the timer1 fix is not longer needed?

Benoit

RE: Integration branch base switchover to Tony's omap-for-linus branch

[Santosh Shilimkar]

> -----Original Message-----
> From: Cousson, Benoit [mailto:b-cousson@ti.com]
> Sent: Tuesday, March 08, 2011 9:58 PM
> To: Shilimkar, Santosh
> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Nayak, Rajendra;
> Hilman, Kevin
> Subject: Re: Integration branch base switchover to Tony's omap-for-
> linus branch
>
> On 3/8/2011 4:16 PM, Shilimkar, Santosh wrote:
> > Paul,
> >> -----Original Message-----
> >> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> >> Sent: Friday, March 04, 2011 10:14 PM
> >> To: Rajendra Nayak
> >> Cc: linux-omap@vger.kernel.org; Benoit Cousson; Paul Walmsley
> >> Subject: RE: Integration branch base switchover to Tony's omap-
> for-
> >> linus branch
> >>
> >
> >   [....]
> >
> >>> Some more debugging by the Hardware team and analyzing
> >>> the register dumps showed that the I2C_WE register of the i2c
> >>> modules needs to be programmed correctly for i2c wakeups to
> >>> function as expected.
> >>> This turned out to be the root cause for the i2c issues observed
> >>> by clearing the staticdeps and a patch has been posted
> >>> to address this...
> >>> http://marc.info/?l=linux-omap&m=129924557219813&w=2
> >>>
> >>>>
> >>>> Also some more testing showed up a lockup in suspend on OMAP4
> >>> which I
> >>>> could narrow down to a similar case with GPT1. Either keeping
> >> the
> >>>> staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use
> >>> software
> >>>> idle control seems to help.
> >>>
> >>> This however is still not rootcaused and is not the same as the
> >>> issue
> >>> seen with i2c as the WE for GPT1 is already programmed for
> >> enabling
> >>> wakeup.
> >>>
> >>> The one way to fix this for now is to put GPT1 block in software
> >>> controlled idle as was done by your test patch for i2c.
> >>>
> >> I tried all the floating patches for static dependency. It did
> >> worked when CPU RET was tried but with MPU OFF I see the hang.
> >>
> >> Below is the global hack I have which works as expected for
> >> all cases.
> >>
> > Thanks to Rajendra for isolating the OMAP4 MPU OFF issue
> > with static dependency series. The issue is isolated
> > to MPU<->  EMIF clock dependency.  There issue appears
> > if we clear this static dependency.
> >
> > I have posted a patch to work-around this issue till its
> > being root-caused with help of hardware team so that
> > OMAP4 PM series continue to work.
> >
> > 'OMAP4: PM: Set static dependency between MPUSS and EMIF'
> > http://www.listware.net/201103/linux-omap/2628-patch-omap4-pm-set-
> static-d
> > ependency-between-mpuss-and-emif.html
>
> Cool, so the timer1 fix is not longer needed?
>
We still need timer fix :(
In summary we need below fixes which came into light with
Static depdency series.

1. I2C: driver fix posted by Rajendra to enable I2C_WE.
2. Timer1: disable hardware-controlled idle
3. clockdomain: Follow PRCM recommended enable sequence
4. MPUSS<-> EMIF static dependency fix.

With above 4 patches instead of global hack of not
clearing static dependency, I tested OMAP4 PM series
and it works as expected.

Regards,
Santosh