On Mon, Nov 22, 2010 at 5:03 PM, Kevin Hilman
<khil...@deeprootsystems.com> wrote:
> "Peter 'p2' De Schrijver" <peter.de-schrij...@nokia.com> writes:
>
>> On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
>>> >-----Original Message-----
>>> >From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
>>> >Sent: Friday, November 19, 2010 9:37 AM
>>>
>>> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pi...@newoldbits.com> 
>>> >>wrote:
>>> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <t...@atomide.com> wrote:
>>> >>> * Jean Pihet <jean.pi...@newoldbits.com> [101118 10:06]:
>>> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <t...@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?
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to