From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Derrick, David" <dderrick@ti.com>
Cc: "Nayak, Rajendra" <rnayak@ti.com>,
"Högander Jouni" <jouni.hogander@nokia.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Woodruff, Richard" <r-woodruff2@ti.com>
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
Date: Tue, 16 Jun 2009 10:28:25 -0700 [thread overview]
Message-ID: <87d4942ime.fsf@deeprootsystems.com> (raw)
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC6536982E1@dlee03.ent.ti.com> (David Derrick's message of "Tue\, 16 Jun 2009 11\:12\:31 -0500")
Hi David,
Thanks for the extra clarifications. Is this Table you sent in the
TRM somewhere? I don't find it in my ES3.1 NDA TRM ver. P.
For the various C-states in CPUidle, we do indeed have various
combinations of MPU and CORE state, from cpuidle34xx.c:
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
* C1 . MPU WFI + Core active
* C2 . MPU WFI + Core inactive
* C3 . MPU CSWR + Core inactive
* C4 . MPU OFF + Core inactive
* C5 . MPU CSWR + Core CSWR
* C6 . MPU OFF + Core CSWR
* C7 . MPU OFF + Core OFF
*/
Maybe the right solution is to have the PRM_VOLTCTRL value associated
with the C-state so we minimize the amount of conditional logic we
have to do in idle loop itself. Otherwise tracking all these
combinations in the idle loop could get ugly. We also don't currently
do anything with AUTO_SLEEP, and it looks like we should.
But, getting back to the original patch, based on the table you sent,
the description in the original patch makes even less sense to me. It
says basically that AUTO_RET and AUTO_OFF are mutually exclusive. The
table suggests otherwise, and shows that you'll never hit 0V unless
both are set.
So I still think the original patch description needs an update.
Kevin
"Derrick, David" <dderrick@ti.com> writes:
> Kevin,
>
>
>
> Not sure this change has been done yet. But basically when you have mis-matched
> power states between the MPU and CORE, you may run into a situation where the
> voltage does not scale. As long as both MPU and CORE go into the same power
> state then there is not a problem. See the following table to better
> understand:
>
>
>
>
> Table 1. AUTO Voltage Scaling
>
> +----------------------------------------------------------------------------------------------------+
> |MPU Power |CORE Power State |AUTO_OFF |AUTO_RETENTION |AUTO_SLEEP |VDD1 |VDD2 |
> |State | | | | | | |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OFF | 0 | 1 | 1 | 1.0V | 0.9V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OFF | 0 | 1 | 0 | 0.9V | 0.9V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OFF | 1 | 1 | 1 |0V/0.6V*|0V/0.6mV* |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OSWR or CSWR | 0 | 1 | 1 | 1.0V | 0.9V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OSWR or CSWR | 0 | 1 | 0 | 0.9V | 0.9V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | OFF | OSWR or CSWR | 1 | 1 | 1 | 1.2V | 1.15V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | CSWR | ON (INACTIVE) | 0 | 1 | 0 | 0.9V | 1.15V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | CSWR | ON (INACTIVE) | 0 | 1 | 1 | 0.9V | 1.0V |
> |---------------+-----------------+------------+------------------+--------------+--------+----------|
> | CSWR | ON (INACTIVE) | 0 | 0 | 1 | 1.0V | 1.0V |
> +----------------------------------------------------------------------------------------------------+
>
> * Using SYS_OFFMODE / Using I2C4
>
>
>
>
>
> You need to dynamically enable and disable the auto voltage scaling (AUTO_OFF,
> AUTO_RET and AUTO_SLEEP) based on which sleep configuration you are going into
> for MPU and CORE.
>
>
>
> Regards,
>
> David
>
>
>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Tuesday, June 16, 2009 9:28 AM
> To: Nayak, Rajendra
> Cc: Högander Jouni; linux-omap@vger.kernel.org; Derrick, David; Woodruff,
> Richard
> Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being
> enabled simultaneously
>
>
>
> "Nayak, Rajendra" <rnayak@ti.com> writes:
>
>
>
>>From: Högander Jouni [mailto:jouni.hogander@nokia.com]
>
>>>
>
>>>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>>>
>
>>>> There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF
>
>>>> should not be set together. The PRCM FSM has been coded assuming
>
>>>> that SW will set either auto_ret or auto_off bit depending on
>
>>>> whether the core has been programmed to go into open switched
>
>>>> logic retention state or OFF state. They are mutually exclusive.
>
>>>
>
>>>So we don't have to do this if closed switch retention is used? (This
>
>>>is what is currently used in linux-omap:pm)
>
>>
>
>> Currently in the pm branch AUTO_RET is enabled at init and kept
>
>> enabled. While attempting a OFF state AUTO_OFF is enabled also
>
>> leaving AUTO_RET and AUTO_OFF both enabled.
>
>
>
> A little more clarification needed, in particular whether or how
>
> this affects closed-switch retention.
>
>
>
> The description above states that this problem affects OSWR and OFF.
>
> linux-omap PM only uses CSWR, so based on the description of the PRCM
>
> FSM above, for CSWR, we should never be setting AUTO_RET when using
>
> CSWR.
>
>
>
> Kevin
>
>
--
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
next prev parent reply other threads:[~2009-06-16 17:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 11:52 [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms Rajendra Nayak
2009-06-16 11:52 ` [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously Rajendra Nayak
2009-06-16 11:52 ` [PATCH 03/04] OMAP3: PM: Fix I2C voltage levels send to T2 for different Power modes Rajendra Nayak
2009-06-16 11:52 ` [PATCH 04/04] OMAP3: PM: Update sleep/wakeup sequence and device grp associations Rajendra Nayak
2009-06-29 22:29 ` Kevin Hilman
2009-06-29 21:48 ` [PATCH 03/04] OMAP3: PM: Fix I2C voltage levels send to T2 for different Power modes Kevin Hilman
2009-06-16 12:39 ` [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously Högander Jouni
2009-06-16 13:16 ` Nayak, Rajendra
2009-06-16 14:28 ` Kevin Hilman
[not found] ` <92CDD168D1E81F4F9D3839DC45903FC6536982E1@dlee03.ent.ti.com>
2009-06-16 17:28 ` Kevin Hilman [this message]
2009-06-17 16:52 ` Derrick, David
2009-06-17 6:27 ` Nayak, Rajendra
2009-06-29 21:45 ` Kevin Hilman
2009-06-16 12:52 ` [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms Högander Jouni
2009-06-16 13:17 ` Nayak, Rajendra
2009-06-16 14:21 ` Kevin Hilman
2009-06-16 16:09 ` Derrick, David
2009-06-17 8:33 ` Paul Walmsley
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=87d4942ime.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=dderrick@ti.com \
--cc=jouni.hogander@nokia.com \
--cc=linux-omap@vger.kernel.org \
--cc=r-woodruff2@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox