Thread (1 message) 1 message, 1 author, 2012-12-28

[PATCH] cpuidle: kirkwood: Move out of mach directory, add DT.

From: Santosh Shilimkar <hidden>
Date: 2012-12-28 17:50:35
Also in: linux-devicetree

On Friday 28 December 2012 10:58 PM, Andrew Lunn wrote:
quoted
Putting DDR/SDRAM into self refresh means, you no longer have RAM
available to execute and any code CPU needs to execute after that has
to be executed either from lock down cache with no cache evictions or
from some internal on chip memory with caches disabled to avoid accesses
to DDR. Not sure how below code works if the first writel puts DDR into
self refresh. Is cpu_do_idle() code copied to some internal memory ?

+	writel(0x7, ddr_operation_base);
+	cpu_do_idle();

May be I am missing something but i have worked on such a code for OMAP3
kind of devices and seen major issues with DDR self refresh and CPU
entering into idle state.
Quoting the datasheet:

   To place the SDRAM into self refresh set the <Cmd> field in the
   SDRAM Operation Register (Table 174 p. 400) to 0x7. The SDRAM
   controller waits for 256 cycles and then generates a self refresh
   command to SDRAM, and clears the SDRAM Operation register.
Thanks for additional info.
I assume we always manage to execute the WFI within these 256 cycles.

There is also some text about handling new pending transactions, so
even if it does not WFI, e.g. because of an interrupts, it seems to do
the right thing.
Is this single CPU or multi-cpu machine ? Even though the cpu_do_idle()
has just couple of instructions, there can be lot more happening in
background especially with multi masters system. It might be safe if the
single CPU is the only master accessing DDR. In multi-master, multi-CPU
scenario though it can't work reliably.

Regards
Santosh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help