On Mon, Nov 22, 2010 at 5:03 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> 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? Yes the patch is '[PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy' > > Kevin > >> That still leaves the >> 500 L3 cycle delay though. >> >> 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
