Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 22, 2010 at 05:03:59PM +0100, ext Kevin Hilman wrote:
> "Peter 'p2' De Schrijver" <peter.de-schrijver@xxxxxxxxx> writes:
> 
> > On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
> >> >-----Original Message-----
> >> >From: Jean Pihet [mailto:jean.pihet@xxxxxxxxxxxxxx] 
> >> >Sent: Friday, November 19, 2010 9:37 AM
> >> 
> >> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> >wrote:
> >> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >> >>> * Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> [101118 10:06]:
> >> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >> >>>>
> >> >>>> About the DPLL lock:
> >> >>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
> >> >>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
> >> >>>> idle and the DPLL is already locked. Note: l-o code has no support for
> >> >>>> the voltages OFF and the external clocks OFF.
> >> >>>>
> >> >>>> What to conclude from 1) and 2)? In my test setup ot looks like
> >> >>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
> >> >>>
> >> >>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
> >> >>>
> >> >>> BTW, are you sure you're hitting core idle in your tests?
> >> >> Yes it is OK from the console messages and the counters values in
> >> >> /debug/pm_debug/count.
> >> >>
> >> >> Let me confirm asap with the PRCM registers dump.
> >> 
> >> >Here is what I experimented:
> >> >1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
> >> >2) checked the real state entered in low power mode from the console
> >> >messages, the output of /debug/pm_debug/count and PRCM registers dump
> >> 
> >> >2) is OK, which means that the RET and OFF modes are correctly hit.
> >> 
> >> >Can I conclude from 1) that the wake-up code is not running from the
> >> >cache in RETention?
> >> 
> >> [Derrick, David] 
> >> 
> >> To add some context to the wait_sdrc_ok function and why it was added:
> >> 
> >> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles 
> >> to lock. So you do not want to go back to DDR before DLL is locked. Also, we 
> >> found some times DLL never locked so we introduced the DLL kick procedure to 
> >> force it to lock.
> >> 
> >
> > The root cause for the DLL not locking has been found though and a
> > workaround implemented. So it should work now :) 
> 
> Is the workaround for this reflected in Nishanth's series?

No. It seems not. The workaround needs VDD2 voltage scaling which seems
to be missing now from l-o ?

Cheers,

Peter.
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux