On Friday 28 December 2012 10:58 PM, Andrew Lunn wrote:
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
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
