>-----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. Regards, David -- 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