linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Vishwanath Sripathy <vishwanath.bs@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
	Eduardo Valentin <eduardo.valentin@nokia.com>,
	Kevin Hilman <khilman@deeprootsystems.com>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Date: Mon, 13 Dec 2010 08:52:52 -0600	[thread overview]
Message-ID: <4D063344.2010001@ti.com> (raw)
In-Reply-To: <6f507e24d6ae188e265913e85e815f82@mail.gmail.com>

Vishwanath Sripathy had written, on 12/13/2010 08:48 AM, the following:
>> -----Original Message-----
>> From: Nishanth Menon [mailto:nm@ti.com]
>> Sent: Monday, December 13, 2010 8:14 PM
>> To: Vishwanath Sripathy
>> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
>> Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
>> coreoff if < ES1.2
>>
>>> -----Original Message-----
>>> Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
>> following:
>>> [...]
>>>>>>>>> +	if
>> (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
>>>>> &&
>>>>>>>>> +			(core_next_state ==
>> PWRDM_POWER_OFF))
>>>>> {
>>>>>>>>> +		pwrdm_set_next_pwrst(core_pwrdm,
>>>>>>>>> PWRDM_POWER_RET);
>>>>>>>>> +		core_next_state = PWRDM_POWER_RET;
>>>>>>>>> +	}
>>>>>>>> Since next_state in pwrst_list (for core) is not updated, this
> is
>>>>>> throwing
>>>>>>>> up an error "Powerdomain (core_pwrdm) didn't enter target
>> state
>>>>> 0"
>>>>>>> when
>>>>>>>> you off mode is enabled for ES1.1 or lesser (in suspend path).
>> It's
>>>>>> not
>>>>>>>> really true that Core has not entered target state. It has
>> entered
>>>>>>>> Retention state which is the actual target state set in
>>>>>> omap_sram_idle.
>>>>>>>> However it did not enter the state that was passed by
>>>>>>> omap3_pm_suspend. Is
>>>>>>>> this expected behavior?
>>>>>>> we could go both ways on this - this patch will(as you noticed)
>>>>> indicate
>>>>>>> that the transition failed on <ES1.2, or we could make it
>> entirely
>>>>>>> transparent(by modifying the the pwrst_list - claim we achieved
>> off,
>>>>>>> while not really hitting off - I personally dont think that is
>>>> correct.
>>>>>> The point I am making is that you cannot distinguish between
>> genuine
>>>>> off
>>>>>> /retention failure since this message is thrown for both pass and
>>>> fail.
>>>>>> May be an additional trace message indicating that system
>> entered
>>>>>> retention instead of off (for ES<1.2) will be useful.
>>>>> hmm... good point there.
>>>>> two issues here:
>>>>> a) omap3_pm_suspend should probably state which state was
>> achieved
>>>>> as
>>>>> well in the error message (trivial fix).
>>>>> b) how do we notify users that it was due to
>>>>> SDRC_WAKEUP_ERRATUM_i583
>>>>> that core-off was denied. -> do this in omap3_pm_suspend(when
>> user
>>>>> attempts actual OFF) OR omap3_pm_off_mode_enable(when user
>>>>> attempts to
>>>>> enable OFF mode)?
>>>>>
>>>>> Any suggestions to allow the same uImage boot on all silicon +
>> allow
>>>>> cpu_idle + suspend paths not to spew pr_info messages(aka cant
>> add
>>>>> prints in sram_idle)?
>>>> I vote for denying off mode for Core (for ES<1.2) in
>>>> omap3_pm_off_mode_enable and throw up a message saying that
>> Core off
>> is
>>>> not enabled. Then we will not get this failure message in suspend
>> path
>>>> since pwrst_list will have the right state.
>>> Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
>> will
>>> deny OFF wholesale if I understand the logic right- not just core-off
> -
>>> I kind of think that is extreme.
>> I take that back, we could do something like the following instead:
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
>> omap2/pm34xx.c
>> index ba3c0d6..74842f1 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int enable)
>>
>>         list_for_each_entry(pwrst, &pwrst_list, node) {
>>                 pwrst->next_state = state;
>> -               omap_set_pwrdm_state(pwrst->pwrdm, state);
>> +               if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
>> &&
>> +                               pwrst->pwrdm == core_pwrdm) {
>> +                       omap_set_pwrdm_state(pwrst->pwrdm,
>> PWRDM_POWER_RET);
> 			You need to update pwrst->next_state as well.
> Otherwise suspend will still throw the same error. I just sent the code in
> other email.
yep. except, I think we dont need to do string compare. the following 
looks any better?

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
  #endif

         list_for_each_entry(pwrst, &pwrst_list, node) {
-               pwrst->next_state = state;
-               omap_set_pwrdm_state(pwrst->pwrdm, state);
+               if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583) &&
+                               pwrst->pwrdm == core_pwrdm) {
+                       pwrst->next_state = PWRDM_POWER_RET;
+                       pr_err("%s: cannot enable Core OFF due to i583\n",
+                               __func__);
+               } else {
+                       pwrst->next_state = state;
+               }
+               omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
         }
  }

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2010-12-13 14:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 17:03 [PATCH 0/5 v3] OMAP: idle path errata fixes Nishanth Menon
2010-12-03 17:03 ` [PATCH 1/5 v2] OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all Nishanth Menon
2010-12-03 17:03 ` [PATCH 2/5 v2] OMAP3: PM: Erratum i581 support: dll kick strategy Nishanth Menon
2010-12-03 17:03 ` [PATCH 3/5 v3] OMAP3630: PM: Erratum i608: disable RTA Nishanth Menon
2010-12-14  3:28   ` Kevin Hilman
2010-12-15 22:13     ` Nishanth Menon
2010-12-16  0:01       ` Kevin Hilman
2010-12-03 17:03 ` [PATCH 4/5 v3] OMAP3630: PM: Disable L2 cache while invalidating L2 cache Nishanth Menon
2010-12-03 17:03 ` [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2 Nishanth Menon
2010-12-13 13:35   ` Vishwanath Sripathy
2010-12-13 13:43     ` Nishanth Menon
2010-12-13 13:54       ` Vishwanath Sripathy
2010-12-13 14:04         ` Nishanth Menon
2010-12-13 14:25           ` Vishwanath Sripathy
2010-12-13 14:36             ` Nishanth Menon
2010-12-13 14:43               ` Nishanth Menon
2010-12-13 14:48                 ` Vishwanath Sripathy
2010-12-13 14:52                   ` Nishanth Menon [this message]
2010-12-13 14:58                     ` Vishwanath Sripathy
2010-12-13 15:02                       ` Nishanth Menon
2010-12-14  3:42                         ` Kevin Hilman
2010-12-15 21:31                           ` Nishanth Menon
2010-12-15 23:47                             ` Kevin Hilman
2010-12-16  0:05                               ` Nishanth Menon
2010-12-16  1:30                                 ` Nishanth Menon
2010-12-16 18:57                                   ` Kevin Hilman
2010-12-17  1:07                                     ` Nishanth Menon
2010-12-17 22:54                                       ` Kevin Hilman
2010-12-17 23:09                                         ` Nishanth Menon
2010-12-20 16:51                                           ` Kevin Hilman
2010-12-13 14:45               ` Vishwanath Sripathy
2010-12-13 14:47                 ` Nishanth Menon
2010-12-08 23:03 ` [PATCH 0/5 v3] OMAP: idle path errata fixes Nishanth Menon
2010-12-14  3:49 ` Kevin Hilman
2010-12-15 21:40   ` Nishanth Menon

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=4D063344.2010001@ti.com \
    --to=nm@ti.com \
    --cc=eduardo.valentin@nokia.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=vishwanath.bs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).