Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
* Jon Hunter [120425 08:16]:
> Hi Tero,
>
> On 04/25/2012 02:33 AM, Tero Kristo wrote:
> > On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
> >> Hi Tero,
> >>
> >> On 04/20/2012 04:33 AM, Tero Kristo wrote:
> >>
> >> [...]
> >>
> >>> +/**
> >>> + * omap4_dpll_print_reg - dump out a single DPLL register value
> >>> + * @dpll_reg: register to dump
> >>> + * @name: name of the register
> >>> + * @tuple: content of the register
> >>> + *
> >>> + * Helper dump function to print out a DPLL register value in case
> >>> + * of restore failures.
> >>> + */
> >>> +static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
> >>> *name,
> >>> + struct dpll_reg *tuple)
> >>> +{
> >>> + if (tuple->offset)
> >>> + pr_warn("%s - Address offset = 0x%08x, value=0x%08x\n", name,
> >>> + tuple->offset, tuple->val);
> >>
> >> Minor nit-pick here ...
> >>
> >> 1. Offset is 16-bits and so we can just have "offset = 0x%04x"
> >> 2. Consider dropping "Address" from "Address offset"
> >> 3. Can we be consistent in our spaces for "offset = " and "value="?
> >>
> >>> +}
> >>> +
> >>> +/*
> >>> + * omap4_dpll_dump_regs - dump out DPLL registers
> >>> + * @dpll_reg: DPLL to dump
> >>> + *
> >>> + * Dump out the contents of the registers for a DPLL. Called if a
> >>> + * restore for DPLL fails to lock.
> >>> + */
> >>> +static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
> >>> +{
> >>> + pr_warn("%s: Unable to lock dpll %s[part=%x inst=%x]:\n",
> >>> + __func__, dpll_reg->name, dpll_reg->mod_partition,
> >>> + dpll_reg->mod_inst);
> >>> + omap4_dpll_print_reg(dpll_reg, "clksel", &dpll_reg->clksel);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m2", &dpll_reg->div_m2);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m3", &dpll_reg->div_m3);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m4", &dpll_reg->div_m4);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m5", &dpll_reg->div_m5);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m6", &dpll_reg->div_m6);
> >>> + omap4_dpll_print_reg(dpll_reg, "div_m7", &dpll_reg->div_m7);
> >>> + omap4_dpll_print_reg(dpll_reg, "clkdcoldo", &dpll_reg->clkdcoldo);
> >>> + omap4_dpll_print_reg(dpll_reg, "clkmode", &dpll_reg->clkmode);
> >>> + omap4_dpll_print_reg(dpll_reg, "autoidle", &dpll_reg->autoidle);
> >>> + if (dpll_reg->idlest.offset)
> >>> + pr_warn("idlest - Address offset = 0x%08x, before val=0x%08x"
> >>> + " after = 0x%08x\n", dpll_reg->idlest.offset,
> >>> + dpll_reg->idlest.val,
> >>> + omap4_dpll_read_reg(dpll_reg, &dpll_reg->idlest));
> >>
> >> Nit-pick ...
> >>
> >> 1. Same comments as above
> >> 2. Consider dropping "Address offset" altogether here as we print
> >> "idlest" the offset should be implied.
> >> 3. Also can we be consistent in our naming of "before val and "after"?
> >> For example, "val before =" and "val now = ".
> >
> > Okay, I'll modify both prints slightly. Question though, do we want
> > these prints in the kernel in the first place? At least Tony has been
> > frowning upon register dumps in the kernel and this falls into that
> > category. What we could do is just to print the warning but drop the
> > register dumps out.
>
> Thanks. Good question. If we are not seeing failures often, and I would
> hope not, probably ok to remove. However, I will let Tony comment here ...
Well if the register dumps really help trace the issue and don't happen
continuously I'm fine with them.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:28:17, Shilimkar, Santosh wrote: > On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav wrote: > > On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: > >> On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav > >> wrote: > >> > > >> > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: > >> > [...] > >> > > >> > > >> 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. > >> > > > > >> > > You don't have to do any real measurements at least on OMAP. > >> > > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect > >> > > bridges to reach to SRAM. DDR is more of direct path and much faster. > >> > > > >> > > >> > Hmm, I was under the impression that OCMC RAM was on L3, at least for > >> > OMAP4. > >> > Maybe there's a extra low latency path for DDR that I am missing. > >> have you folks considered the possibility that SRAM may be > >> reprogrammed by Security code to almost nothing if PA/PPA size needs > >> to be increased? it would be rather dumb not to support HS devices on > >> which real products are made, no? rule of thumb has been to avoid > >> usage of SRAM as it constraints security folks as well (yep, I know > >> they should share code with all of us etc.. but they have a different > >> sets of challenges that may deny them such luxury). > >> > > > > Even I would like to avoid the usage of MPUSS SRAM for this very reason. > > But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM > > inside MPUSS). > > On OMAP, even OCMC RAM can be used by security middle-ware apart from > reserved SRAM > for HS/EMU devices. > That's what Nishant meant. > Oh ok. I wasn't aware of this aspect. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav wrote: > On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: >> On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav wrote: >> > >> > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: >> > [...] >> > >> > > >> 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. >> > > > >> > > You don't have to do any real measurements at least on OMAP. >> > > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect >> > > bridges to reach to SRAM. DDR is more of direct path and much faster. >> > > >> > >> > Hmm, I was under the impression that OCMC RAM was on L3, at least for >> > OMAP4. >> > Maybe there's a extra low latency path for DDR that I am missing. >> have you folks considered the possibility that SRAM may be >> reprogrammed by Security code to almost nothing if PA/PPA size needs >> to be increased? it would be rather dumb not to support HS devices on >> which real products are made, no? rule of thumb has been to avoid >> usage of SRAM as it constraints security folks as well (yep, I know >> they should share code with all of us etc.. but they have a different >> sets of challenges that may deny them such luxury). >> > > Even I would like to avoid the usage of MPUSS SRAM for this very reason. > But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside > MPUSS). On OMAP, even OCMC RAM can be used by security middle-ware apart from reserved SRAM for HS/EMU devices. That's what Nishant meant. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: > On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav wrote: > > > > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: > > [...] > > > > > >> 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. > > > > > > > You don't have to do any real measurements at least on OMAP. > > > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect > > > bridges to reach to SRAM. DDR is more of direct path and much faster. > > > > > > > Hmm, I was under the impression that OCMC RAM was on L3, at least for > > OMAP4. > > Maybe there's a extra low latency path for DDR that I am missing. > have you folks considered the possibility that SRAM may be > reprogrammed by Security code to almost nothing if PA/PPA size needs > to be increased? it would be rather dumb not to support HS devices on > which real products are made, no? rule of thumb has been to avoid > usage of SRAM as it constraints security folks as well (yep, I know > they should share code with all of us etc.. but they have a different > sets of challenges that may deny them such luxury). > Even I would like to avoid the usage of MPUSS SRAM for this very reason. But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside MPUSS). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 17:16:19, Shilimkar, Santosh wrote: > On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav wrote: > > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: > > [...] > > > >> >> 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. > >> > > >> You don't have to do any real measurements at least on OMAP. > >> OCMC RAM is interfaced over L4 and MPU has to cross two interconnect > >> bridges to reach to SRAM. DDR is more of direct path and much faster. > >> > > > > Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. > Nope. It's on L4 and it is same for all OMAPs including OMAP5 > > > Maybe there's a extra low latency path for DDR that I am missing. > Even OMAP3 DDR is faster than OCMC RAM. > Ok. I guess I need to come up with some data for AM33x then. Thanks for the clarification. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav wrote: > > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: > [...] > > > >> 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. > > > > > You don't have to do any real measurements at least on OMAP. > > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect > > bridges to reach to SRAM. DDR is more of direct path and much faster. > > > > Hmm, I was under the impression that OCMC RAM was on L3, at least for > OMAP4. > Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav wrote: > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: > [...] > >> >> 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. >> > >> You don't have to do any real measurements at least on OMAP. >> OCMC RAM is interfaced over L4 and MPU has to cross two interconnect >> bridges to reach to SRAM. DDR is more of direct path and much faster. >> > > Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Nope. It's on L4 and it is same for all OMAPs including OMAP5 > Maybe there's a extra low latency path for DDR that I am missing. Even OMAP3 DDR is faster than OCMC RAM. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] > >> 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. > > > You don't have to do any real measurements at least on OMAP. > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect > bridges to reach to SRAM. DDR is more of direct path and much faster. > Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 4:25 PM, Bedia, Vaibhav wrote:
> On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
>> On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav wrote:
>> > Hi Tero,
>> >
>> > On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
>> >> From: Rajendra Nayak
>> >>
[...]
>>
>> [...]
>> >> +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.
>
You don't have to do any real measurements at least on OMAP.
OCMC RAM is interfaced over L4 and MPU has to cross two interconnect
bridges to reach to SRAM. DDR is more of direct path and much faster.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
> On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav wrote:
> > Hi Tero,
> >
> > On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
> >> From: Rajendra Nayak
> >>
> >> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav wrote:
> Hi Tero,
>
> On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
>> From: Rajendra Nayak
>>
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
> From: Rajendra Nayak
>
> 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.
> [n...@ti.com: minor cleanups]
> Signed-off-by: Nishanth Menon
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/cm44xx.h |5 +
> arch/arm/mach-omap2/dpll44xx.c | 271
>
> 2 files changed, 276 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
> index 3380bee..5fba0fa 100644
> --- a/arch/arm/mach-omap2/cm44xx.h
> +++ b/arch/arm/mach-omap2/cm44xx.h
> @@ -23,4 +23,9 @@
> #define OMAP4_CM_CLKSTCTRL 0x
> #define OMAP4_CM_STATICDEP 0x0004
>
> +#ifndef __ASSEMBLER__
> +extern void omap4_dpll_prepare_off(void);
> +extern void omap4_dpll_resume_off(void);
> +#endif
> +
> #endif
> diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
> index 9c6a296..b411d3b 100644
> --- a/arch/arm/mach-omap2/dpll44xx.c
> +++ b/arch/arm/mach-omap2/dpll44xx.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -21,6 +22,96 @@
> #include "clock.h"
> #include "clock44xx.h"
> #include "cm-regbits-44xx.h"
> +#include "cm1_44xx.h"
> +#include "cm2_44xx.h"
> +#include "prcm44xx.h"
> +#include "cminst44xx.h"
> +#include "cm44xx.h"
> +
> +#define MAX_DPLL_WAIT_TRIES 100
> +
> +struct dpll_reg {
> + u16 offset;
> + u32 val;
> +};
> +
> +struct omap4_dpll_regs {
> + char *name;
> + u32 mod_partition;
> + u32 mod_inst;
> + struct dpll_reg clkmode;
> + struct dpll_reg autoidle;
> + struct dpll_reg idlest;
> + struct dpll_reg clksel;
> + struct dpll_reg div_m2;
> + struct dpll_reg div_m3;
> + struct dpll_reg div_m4;
> + struct dpll_reg div_m5;
> + struct dpll_reg div_m6;
> + struct dpll_reg div_m7;
> + struct dpll_reg clkdcoldo;
> +};
> +
> +static struct omap4_dpll_regs dpll_regs[] = {
> + /* MPU DPLL */
> + { .name = "mpu",
> + .mod_partition = OMAP4430_CM1_PARTITION,
> + .mod_inst = OMAP4430_CM1_CKGEN_INST,
> + .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_MPU_OFFSET},
> + .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_MPU_OFFSET},
> + .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_MPU_OFFSET},
> + .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_MPU_OFFSET},
> + .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_MPU_OFFSET},
> + },
> + /* IVA DPLL */
> + { .name = "iva",
> + .mod_partition = OMAP4430_CM1_PARTITION,
> + .mod_inst = OMAP4430_CM1_CKGEN_INST,
> + .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_IVA_OFFSET},
> + .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_IVA_OFFSET},
> + .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_IVA_OFFSET},
> + .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_IVA_OFFSET},
> + .div_m4 = {.offset = OMAP4_CM_DIV_M4_DPLL_IVA_OFFSET},
> + .div_m5 = {.offset = OMAP4_CM_DIV_M5_DPLL_IVA_OFFSET},
> + },
> + /* ABE DPLL */
> + { .name = "abe",
> + .mod_partition = OMAP4430_CM1_PARTITION,
> + .mod_inst = OMAP4430_CM1_CKGEN_INST,
> + .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_ABE_OFFSET},
> + .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_ABE_OFFSET},
> + .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_ABE_OFFSET},
> + .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_ABE_OFFSET},
> + .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_ABE_OFFSET},
> + .div_m3 = {.offset = OMAP4_CM_DIV_M3_DPLL_ABE_OFFSET},
> + },
> + /* USB DPLL */
> + { .name = "usb",
> + .mod_partition = OMAP4430_CM2_PARTITION,
> + .mod_inst = OMAP4430_CM2_CKGEN_INST,
> + .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_USB_OFFSET},
> + .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_USB_OF
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On 04/25/2012 02:33 AM, Tero Kristo wrote:
> On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
>> Hi Tero,
>>
>> On 04/20/2012 04:33 AM, Tero Kristo wrote:
>>
>> [...]
>>
>>> +/**
>>> + * omap4_dpll_print_reg - dump out a single DPLL register value
>>> + * @dpll_reg: register to dump
>>> + * @name: name of the register
>>> + * @tuple: content of the register
>>> + *
>>> + * Helper dump function to print out a DPLL register value in case
>>> + * of restore failures.
>>> + */
>>> +static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
>>> *name,
>>> +struct dpll_reg *tuple)
>>> +{
>>> + if (tuple->offset)
>>> + pr_warn("%s - Address offset = 0x%08x, value=0x%08x\n", name,
>>> + tuple->offset, tuple->val);
>>
>> Minor nit-pick here ...
>>
>> 1. Offset is 16-bits and so we can just have "offset = 0x%04x"
>> 2. Consider dropping "Address" from "Address offset"
>> 3. Can we be consistent in our spaces for "offset = " and "value="?
>>
>>> +}
>>> +
>>> +/*
>>> + * omap4_dpll_dump_regs - dump out DPLL registers
>>> + * @dpll_reg: DPLL to dump
>>> + *
>>> + * Dump out the contents of the registers for a DPLL. Called if a
>>> + * restore for DPLL fails to lock.
>>> + */
>>> +static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
>>> +{
>>> + pr_warn("%s: Unable to lock dpll %s[part=%x inst=%x]:\n",
>>> + __func__, dpll_reg->name, dpll_reg->mod_partition,
>>> + dpll_reg->mod_inst);
>>> + omap4_dpll_print_reg(dpll_reg, "clksel", &dpll_reg->clksel);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m2", &dpll_reg->div_m2);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m3", &dpll_reg->div_m3);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m4", &dpll_reg->div_m4);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m5", &dpll_reg->div_m5);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m6", &dpll_reg->div_m6);
>>> + omap4_dpll_print_reg(dpll_reg, "div_m7", &dpll_reg->div_m7);
>>> + omap4_dpll_print_reg(dpll_reg, "clkdcoldo", &dpll_reg->clkdcoldo);
>>> + omap4_dpll_print_reg(dpll_reg, "clkmode", &dpll_reg->clkmode);
>>> + omap4_dpll_print_reg(dpll_reg, "autoidle", &dpll_reg->autoidle);
>>> + if (dpll_reg->idlest.offset)
>>> + pr_warn("idlest - Address offset = 0x%08x, before val=0x%08x"
>>> + " after = 0x%08x\n", dpll_reg->idlest.offset,
>>> + dpll_reg->idlest.val,
>>> + omap4_dpll_read_reg(dpll_reg, &dpll_reg->idlest));
>>
>> Nit-pick ...
>>
>> 1. Same comments as above
>> 2. Consider dropping "Address offset" altogether here as we print
>> "idlest" the offset should be implied.
>> 3. Also can we be consistent in our naming of "before val and "after"?
>> For example, "val before =" and "val now = ".
>
> Okay, I'll modify both prints slightly. Question though, do we want
> these prints in the kernel in the first place? At least Tony has been
> frowning upon register dumps in the kernel and this falls into that
> category. What we could do is just to print the warning but drop the
> register dumps out.
Thanks. Good question. If we are not seeing failures often, and I would
hope not, probably ok to remove. However, I will let Tony comment here ...
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
> Hi Tero,
>
> On 04/20/2012 04:33 AM, Tero Kristo wrote:
>
> [...]
>
> > +/**
> > + * omap4_dpll_print_reg - dump out a single DPLL register value
> > + * @dpll_reg: register to dump
> > + * @name: name of the register
> > + * @tuple: content of the register
> > + *
> > + * Helper dump function to print out a DPLL register value in case
> > + * of restore failures.
> > + */
> > +static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
> > *name,
> > +struct dpll_reg *tuple)
> > +{
> > + if (tuple->offset)
> > + pr_warn("%s - Address offset = 0x%08x, value=0x%08x\n", name,
> > + tuple->offset, tuple->val);
>
> Minor nit-pick here ...
>
> 1. Offset is 16-bits and so we can just have "offset = 0x%04x"
> 2. Consider dropping "Address" from "Address offset"
> 3. Can we be consistent in our spaces for "offset = " and "value="?
>
> > +}
> > +
> > +/*
> > + * omap4_dpll_dump_regs - dump out DPLL registers
> > + * @dpll_reg: DPLL to dump
> > + *
> > + * Dump out the contents of the registers for a DPLL. Called if a
> > + * restore for DPLL fails to lock.
> > + */
> > +static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
> > +{
> > + pr_warn("%s: Unable to lock dpll %s[part=%x inst=%x]:\n",
> > + __func__, dpll_reg->name, dpll_reg->mod_partition,
> > + dpll_reg->mod_inst);
> > + omap4_dpll_print_reg(dpll_reg, "clksel", &dpll_reg->clksel);
> > + omap4_dpll_print_reg(dpll_reg, "div_m2", &dpll_reg->div_m2);
> > + omap4_dpll_print_reg(dpll_reg, "div_m3", &dpll_reg->div_m3);
> > + omap4_dpll_print_reg(dpll_reg, "div_m4", &dpll_reg->div_m4);
> > + omap4_dpll_print_reg(dpll_reg, "div_m5", &dpll_reg->div_m5);
> > + omap4_dpll_print_reg(dpll_reg, "div_m6", &dpll_reg->div_m6);
> > + omap4_dpll_print_reg(dpll_reg, "div_m7", &dpll_reg->div_m7);
> > + omap4_dpll_print_reg(dpll_reg, "clkdcoldo", &dpll_reg->clkdcoldo);
> > + omap4_dpll_print_reg(dpll_reg, "clkmode", &dpll_reg->clkmode);
> > + omap4_dpll_print_reg(dpll_reg, "autoidle", &dpll_reg->autoidle);
> > + if (dpll_reg->idlest.offset)
> > + pr_warn("idlest - Address offset = 0x%08x, before val=0x%08x"
> > + " after = 0x%08x\n", dpll_reg->idlest.offset,
> > + dpll_reg->idlest.val,
> > + omap4_dpll_read_reg(dpll_reg, &dpll_reg->idlest));
>
> Nit-pick ...
>
> 1. Same comments as above
> 2. Consider dropping "Address offset" altogether here as we print
> "idlest" the offset should be implied.
> 3. Also can we be consistent in our naming of "before val and "after"?
> For example, "val before =" and "val now = ".
Okay, I'll modify both prints slightly. Question though, do we want
these prints in the kernel in the first place? At least Tony has been
frowning upon register dumps in the kernel and this falls into that
category. What we could do is just to print the warning but drop the
register dumps out.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
> +/**
> + * omap4_dpll_print_reg - dump out a single DPLL register value
> + * @dpll_reg: register to dump
> + * @name: name of the register
> + * @tuple: content of the register
> + *
> + * Helper dump function to print out a DPLL register value in case
> + * of restore failures.
> + */
> +static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
> *name,
> + struct dpll_reg *tuple)
> +{
> + if (tuple->offset)
> + pr_warn("%s - Address offset = 0x%08x, value=0x%08x\n", name,
> + tuple->offset, tuple->val);
Minor nit-pick here ...
1. Offset is 16-bits and so we can just have "offset = 0x%04x"
2. Consider dropping "Address" from "Address offset"
3. Can we be consistent in our spaces for "offset = " and "value="?
> +}
> +
> +/*
> + * omap4_dpll_dump_regs - dump out DPLL registers
> + * @dpll_reg: DPLL to dump
> + *
> + * Dump out the contents of the registers for a DPLL. Called if a
> + * restore for DPLL fails to lock.
> + */
> +static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
> +{
> + pr_warn("%s: Unable to lock dpll %s[part=%x inst=%x]:\n",
> + __func__, dpll_reg->name, dpll_reg->mod_partition,
> + dpll_reg->mod_inst);
> + omap4_dpll_print_reg(dpll_reg, "clksel", &dpll_reg->clksel);
> + omap4_dpll_print_reg(dpll_reg, "div_m2", &dpll_reg->div_m2);
> + omap4_dpll_print_reg(dpll_reg, "div_m3", &dpll_reg->div_m3);
> + omap4_dpll_print_reg(dpll_reg, "div_m4", &dpll_reg->div_m4);
> + omap4_dpll_print_reg(dpll_reg, "div_m5", &dpll_reg->div_m5);
> + omap4_dpll_print_reg(dpll_reg, "div_m6", &dpll_reg->div_m6);
> + omap4_dpll_print_reg(dpll_reg, "div_m7", &dpll_reg->div_m7);
> + omap4_dpll_print_reg(dpll_reg, "clkdcoldo", &dpll_reg->clkdcoldo);
> + omap4_dpll_print_reg(dpll_reg, "clkmode", &dpll_reg->clkmode);
> + omap4_dpll_print_reg(dpll_reg, "autoidle", &dpll_reg->autoidle);
> + if (dpll_reg->idlest.offset)
> + pr_warn("idlest - Address offset = 0x%08x, before val=0x%08x"
> + " after = 0x%08x\n", dpll_reg->idlest.offset,
> + dpll_reg->idlest.val,
> + omap4_dpll_read_reg(dpll_reg, &dpll_reg->idlest));
Nit-pick ...
1. Same comments as above
2. Consider dropping "Address offset" altogether here as we print
"idlest" the offset should be implied.
3. Also can we be consistent in our naming of "before val and "after"?
For example, "val before =" and "val now = ".
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
From: Rajendra Nayak
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.
[n...@ti.com: minor cleanups]
Signed-off-by: Nishanth Menon
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/cm44xx.h |5 +
arch/arm/mach-omap2/dpll44xx.c | 271
2 files changed, 276 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
index 3380bee..5fba0fa 100644
--- a/arch/arm/mach-omap2/cm44xx.h
+++ b/arch/arm/mach-omap2/cm44xx.h
@@ -23,4 +23,9 @@
#define OMAP4_CM_CLKSTCTRL 0x
#define OMAP4_CM_STATICDEP 0x0004
+#ifndef __ASSEMBLER__
+extern void omap4_dpll_prepare_off(void);
+extern void omap4_dpll_resume_off(void);
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 9c6a296..b411d3b 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -21,6 +22,96 @@
#include "clock.h"
#include "clock44xx.h"
#include "cm-regbits-44xx.h"
+#include "cm1_44xx.h"
+#include "cm2_44xx.h"
+#include "prcm44xx.h"
+#include "cminst44xx.h"
+#include "cm44xx.h"
+
+#define MAX_DPLL_WAIT_TRIES100
+
+struct dpll_reg {
+ u16 offset;
+ u32 val;
+};
+
+struct omap4_dpll_regs {
+ char *name;
+ u32 mod_partition;
+ u32 mod_inst;
+ struct dpll_reg clkmode;
+ struct dpll_reg autoidle;
+ struct dpll_reg idlest;
+ struct dpll_reg clksel;
+ struct dpll_reg div_m2;
+ struct dpll_reg div_m3;
+ struct dpll_reg div_m4;
+ struct dpll_reg div_m5;
+ struct dpll_reg div_m6;
+ struct dpll_reg div_m7;
+ struct dpll_reg clkdcoldo;
+};
+
+static struct omap4_dpll_regs dpll_regs[] = {
+ /* MPU DPLL */
+ { .name = "mpu",
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_MPU_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_MPU_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_MPU_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_MPU_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_MPU_OFFSET},
+ },
+ /* IVA DPLL */
+ { .name = "iva",
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_IVA_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_IVA_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_IVA_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_IVA_OFFSET},
+ .div_m4 = {.offset = OMAP4_CM_DIV_M4_DPLL_IVA_OFFSET},
+ .div_m5 = {.offset = OMAP4_CM_DIV_M5_DPLL_IVA_OFFSET},
+ },
+ /* ABE DPLL */
+ { .name = "abe",
+ .mod_partition = OMAP4430_CM1_PARTITION,
+ .mod_inst = OMAP4430_CM1_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_ABE_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_ABE_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_ABE_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_ABE_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_ABE_OFFSET},
+ .div_m3 = {.offset = OMAP4_CM_DIV_M3_DPLL_ABE_OFFSET},
+ },
+ /* USB DPLL */
+ { .name = "usb",
+ .mod_partition = OMAP4430_CM2_PARTITION,
+ .mod_inst = OMAP4430_CM2_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_USB_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_USB_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_USB_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_USB_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_USB_OFFSET},
+ .clkdcoldo= {.offset = OMAP4_CM_CLKDCOLDO_DPLL_USB_OFFSET},
+},
+ /* PER DPLL */
+ { .name = "per",
+ .mod_partition = OMAP4430_CM2_PARTITION,
+ .mod_inst = OMAP4430_CM2_CKGEN_INST,
+ .clkmode = {.offset = OMAP4_CM_CLKMODE_DPLL_PER_OFFSET},
+ .autoidle = {.offset = OMAP4_CM_AUTOIDLE_DPLL_PER_OFFSET},
+ .idlest = {.offset = OMAP4_CM_IDLEST_DPLL_PER_OFFSET},
+ .clksel = {.offset = OMAP4_CM_CLKSEL_DPLL_PER_OFFSET},
+ .div_m2 = {.offset = OMAP4_CM_DIV_M2_DPLL_PER_OFFSET},
+ .div_m3 = {.offset = OMAP4_CM_DIV_M3_DPLL_PER_OFFSE
