>-----Original Message-----
>From: Jean Pihet [mailto:[email protected]] 
>Sent: Friday, November 19, 2010 9:37 AM

>On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <[email protected]> >wrote:
>> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <[email protected]> wrote:
>>> * Jean Pihet <[email protected]> [101118 10:06]:
>>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <[email protected]> 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.

Regards,
David

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to