[PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

[Bedia, Vaibhav]

On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
> On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav <vaibhav.bedia at ti.com> wrote:
> > Hi Tero,
> >
> > On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
> >> From: Rajendra Nayak <rnayak at ti.com>
> >>
> >> 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.

I was afraid of that. If all the read-only registers were clubbed together
a lot of code could have been removed. Looking more closely at the TRM
I guess we can't really ask design folks to club those read-only registers
in the future. So scratch this.

> 
> [...]
> >> +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.
> 

I am just guessing if that's indeed the case ;) 
Haven't done any measurements to really check if that's indeed the case though.