On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav <vaibhav.bedia@xxxxxx> wrote:
> Hi Tero,
>
> On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
>> From: Rajendra Nayak <rnayak@xxxxxx>
>>
>> SAR/ROM code restores only CORE DPLL to its original state
>> post wakeup from OFF mode.
>> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
>> are saved and restored here during an OFF transition.
>>
>
> Most of the registers being saved and restored in the various
> patches look to be contiguous. So, instead of a long list of these
> contiguous registers how about having a generic API for backup and
> restore of the registers contents based on the memory address range?
>
> Most of the registers which require save and restore are either part
> of PRM, CM or Control. The PRM or CM instance could be passed as the
> base and the save/restore API could work around that.
>
> One downside is that there are some read-only registers in between but
> I don't see any simple way of avoiding save and restore of those. BTW,
> as per the TRM that I have, this patch is also doing save and restore
> of some read-only registers.
>
You should never write to read-only registers since the behavior is
undefined.
[...]
>> +void omap4_dpll_resume_off(void)
>> +{
>> + u32 i;
>> + struct omap4_dpll_regs *dpll_reg = dpll_regs;
>> +
>> + for (i = 0; i < ARRAY_SIZE(dpll_regs); i++, dpll_reg++) {
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->clksel);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m2);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m3);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m4);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m5);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m6);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->div_m7);
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->clkdcoldo);
>> +
>> + /* Restore clkmode after the above registers are restored */
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->clkmode);
>> +
>> + omap4_wait_dpll_lock(dpll_reg);
>> +
>> + /* Restore autoidle settings after the dpll is locked */
>> + omap4_dpll_restore_reg(dpll_reg, &dpll_reg->autoidle);
>> + }
>> +}
>
> If this function is placed in SRAM and PER PLL restored just after MPU
> won't the exit latency be further optimized?
>
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
--
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
