Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

[Kevin Hilman <khilman@deeprootsystems.com>]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>>"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.
>
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html