Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
- From: "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx>
- Date: Wed, 2 May 2012 15:48:01 +0530
- Cc: "Kristo, Tero" <t-kristo@xxxxxx>, "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx>, "Hilman, Kevin" <khilman@xxxxxx>, "paul@xxxxxxxxx" <paul@xxxxxxxxx>, "Menon, Nishanth" <nm@xxxxxx>, "Nayak, Rajendra" <rnayak@xxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <B5906170F1614E41A8A28DE3B8D121433EA6B68E@DBDE01.ent.ti.com>
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
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]