* Integration branch base switchover to Tony's omap-for-linus branch @ 2011-02-26 0:26 Paul Walmsley 2011-03-01 12:38 ` Santosh Shilimkar 0 siblings, 1 reply; 14+ messages in thread From: Paul Walmsley @ 2011-02-26 0:26 UTC (permalink / raw) To: linux-omap 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-02-26 0:26 Integration branch base switchover to Tony's omap-for-linus branch Paul Walmsley @ 2011-03-01 12:38 ` Santosh Shilimkar 2011-03-01 21:33 ` Paul Walmsley 0 siblings, 1 reply; 14+ messages in thread From: Santosh Shilimkar @ 2011-03-01 12:38 UTC (permalink / raw) To: Paul Walmsley, Rajendra Nayak; +Cc: linux-omap 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 ]--- ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-01 12:38 ` Santosh Shilimkar @ 2011-03-01 21:33 ` Paul Walmsley 2011-03-03 12:30 ` Rajendra Nayak 0 siblings, 1 reply; 14+ messages in thread From: Paul Walmsley @ 2011-03-01 21:33 UTC (permalink / raw) To: Santosh Shilimkar; +Cc: Rajendra Nayak, linux-omap 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-01 21:33 ` Paul Walmsley @ 2011-03-03 12:30 ` Rajendra Nayak 2011-03-04 14:08 ` Rajendra Nayak 0 siblings, 1 reply; 14+ messages in thread From: Rajendra Nayak @ 2011-03-03 12:30 UTC (permalink / raw) To: Paul Walmsley; +Cc: Santosh Shilimkar, linux-omap 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, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-03 12:30 ` Rajendra Nayak @ 2011-03-04 14:08 ` Rajendra Nayak 2011-03-04 14:59 ` Cousson, Benoit ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Rajendra Nayak @ 2011-03-04 14:08 UTC (permalink / raw) To: Paul Walmsley; +Cc: Santosh Shilimkar, linux-omap [-- 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 14:08 ` Rajendra Nayak @ 2011-03-04 14:59 ` Cousson, Benoit 2011-03-04 15:01 ` Santosh Shilimkar 2011-03-04 16:43 ` Santosh Shilimkar 2011-03-07 23:25 ` Paul Walmsley 2 siblings, 1 reply; 14+ messages in thread From: Cousson, Benoit @ 2011-03-04 14:59 UTC (permalink / raw) To: Nayak, Rajendra; +Cc: Paul Walmsley, Shilimkar, Santosh, linux-omap 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 14:59 ` Cousson, Benoit @ 2011-03-04 15:01 ` Santosh Shilimkar 2011-03-04 15:25 ` Cousson, Benoit 0 siblings, 1 reply; 14+ messages in thread From: Santosh Shilimkar @ 2011-03-04 15:01 UTC (permalink / raw) To: Benoit Cousson, Rajendra Nayak; +Cc: Paul Walmsley, linux-omap > -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 15:01 ` Santosh Shilimkar @ 2011-03-04 15:25 ` Cousson, Benoit 0 siblings, 0 replies; 14+ messages in thread From: Cousson, Benoit @ 2011-03-04 15:25 UTC (permalink / raw) To: Shilimkar, Santosh; +Cc: Nayak, Rajendra, Paul Walmsley, linux-omap 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 14:08 ` Rajendra Nayak 2011-03-04 14:59 ` Cousson, Benoit @ 2011-03-04 16:43 ` Santosh Shilimkar 2011-03-08 15:16 ` Santosh Shilimkar 2011-03-07 23:25 ` Paul Walmsley 2 siblings, 1 reply; 14+ messages in thread From: Santosh Shilimkar @ 2011-03-04 16:43 UTC (permalink / raw) To: Rajendra Nayak; +Cc: linux-omap, Benoit Cousson, Paul Walmsley [-- 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 16:43 ` Santosh Shilimkar @ 2011-03-08 15:16 ` Santosh Shilimkar 2011-03-08 16:28 ` Cousson, Benoit 0 siblings, 1 reply; 14+ messages in thread From: Santosh Shilimkar @ 2011-03-08 15:16 UTC (permalink / raw) To: Paul Walmsley; +Cc: linux-omap, Benoit Cousson, Rajendra Nayak, Kevin Hilman 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-08 15:16 ` Santosh Shilimkar @ 2011-03-08 16:28 ` Cousson, Benoit 2011-03-09 5:08 ` Santosh Shilimkar 0 siblings, 1 reply; 14+ messages in thread From: Cousson, Benoit @ 2011-03-08 16:28 UTC (permalink / raw) To: Shilimkar, Santosh Cc: Paul Walmsley, linux-omap, Nayak, Rajendra, Hilman, Kevin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-08 16:28 ` Cousson, Benoit @ 2011-03-09 5:08 ` Santosh Shilimkar 0 siblings, 0 replies; 14+ messages in thread From: Santosh Shilimkar @ 2011-03-09 5:08 UTC (permalink / raw) To: Benoit Cousson; +Cc: Paul Walmsley, linux-omap, Rajendra Nayak, Kevin Hilman > -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-04 14:08 ` Rajendra Nayak 2011-03-04 14:59 ` Cousson, Benoit 2011-03-04 16:43 ` Santosh Shilimkar @ 2011-03-07 23:25 ` Paul Walmsley 2011-03-08 8:04 ` Cousson, Benoit 2 siblings, 1 reply; 14+ messages in thread From: Paul Walmsley @ 2011-03-07 23:25 UTC (permalink / raw) To: Rajendra Nayak, b-cousson; +Cc: Santosh Shilimkar, linux-omap [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Integration branch base switchover to Tony's omap-for-linus branch 2011-03-07 23:25 ` Paul Walmsley @ 2011-03-08 8:04 ` Cousson, Benoit 0 siblings, 0 replies; 14+ messages in thread From: Cousson, Benoit @ 2011-03-08 8:04 UTC (permalink / raw) To: Paul Walmsley; +Cc: Nayak, Rajendra, Shilimkar, Santosh, linux-omap 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-03-09 5:08 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-26 0:26 Integration branch base switchover to Tony's omap-for-linus branch Paul Walmsley 2011-03-01 12:38 ` Santosh Shilimkar 2011-03-01 21:33 ` Paul Walmsley 2011-03-03 12:30 ` Rajendra Nayak 2011-03-04 14:08 ` Rajendra Nayak 2011-03-04 14:59 ` Cousson, Benoit 2011-03-04 15:01 ` Santosh Shilimkar 2011-03-04 15:25 ` Cousson, Benoit 2011-03-04 16:43 ` Santosh Shilimkar 2011-03-08 15:16 ` Santosh Shilimkar 2011-03-08 16:28 ` Cousson, Benoit 2011-03-09 5:08 ` Santosh Shilimkar 2011-03-07 23:25 ` Paul Walmsley 2011-03-08 8:04 ` Cousson, Benoit
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.