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

[Kevin Hilman <khilman@deeprootsystems.com>]

"Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:

> On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
>> >-----Original Message-----
>> >From: Jean Pihet [mailto:jean.pihet@newoldbits.com] 
>> >Sent: Friday, November 19, 2010 9:37 AM
>> 
>> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
>> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> 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?

Kevin

> That still leaves the
> 500 L3 cycle delay though.
>
> Cheers,
>
> Peter.