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@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, June 16, 2009 9:28 AM > To: Nayak, Rajendra > Cc: Högander Jouni; linux-omap@xxxxxxxxxxxxxxx; Derrick, David; Woodruff, > Richard > Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being > enabled simultaneously > > > > "Nayak, Rajendra" <rnayak@xxxxxx> writes: > > > >>From: Högander Jouni [mailto:jouni.hogander@xxxxxxxxx] > >>> > >>>ext Rajendra Nayak <rnayak@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
