All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: linux-omap@vger.kernel.org, Benoit Cousson <b-cousson@ti.com>,
	Paul Walmsley <paul@pwsan.com>
Subject: RE: Integration branch base switchover to Tony's omap-for-linus branch
Date: Fri, 4 Mar 2011 22:13:38 +0530	[thread overview]
Message-ID: <58ec7480fe87b4d64c33cb2c4454a805@mail.gmail.com> (raw)
In-Reply-To: <4D70F25C.4040206@ti.com>

[-- 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


  parent reply	other threads:[~2011-03-04 16:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58ec7480fe87b4d64c33cb2c4454a805@mail.gmail.com \
    --to=santosh.shilimkar@ti.com \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.