On Fri, Nov 19, 2010 at 5:14 PM, Derrick, David <dderrick@xxxxxx> 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. Ok thanks for the details. Does that mean that it is unsafe to run the sleep code (in sleep34xx.S) from DDR? > > Regards, > David > > Regards, Jean -- 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
