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
next prev parent 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 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.