"Nayak, Rajendra" <rnayak@xxxxxx> writes: >>"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. > > Sorry, that was a wrong description. AUTO_RET could be used to scale the voltage > down even in case of CSWR and not just OSWR. > > The idea of this patch was to enable auto voltage scaling only for the last 3 C states. > > * C5 . MPU CSWR + Core CSWR - AUTO RET enabled > * C6 . MPU OFF + Core CSWR - AUTO RET enabled > * C7 . MPU OFF + Core OFF - AUTO OFF enabled. > > For the rest of the Lower C states the decision of not enabling AUTO > RET/OFF was to keep the latency for such states down. > > Especially with SR enabled having AUTO RET/OFF enabled for say a MPU > RET/CORE inactive state would mean a 2 level voltage change. First > to scale from SR autocompensated level to the actual OPP voltage > level (That's done when you disable SR) and then from the there to > the AUTO RET level. So say you hit MPU RET/CORE inactive state at > OPP3 (1.2v) which has a SR autocompensated voltage to 1.08v, then > you would scale from 1.08->1.2->0.975. That might be too much of > additional latency to incure in case of a MPU RET/CORE inactive > state. > OK, I've updated the patch description on this one and will push to PM branch (and pm-2.6.29) 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
