Am 15.10.2018 um 18:43 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
here is some interesting note from a community member at the boards:
Normally the DLL (Delay-Locked Loop) should only be disabled to run RAM at very low clock speeds (for power saving). Disabling the dynamic DDR RAM clock speed might also fix the issue.
Are we running at a dynamic DDR RAM clock speed? Or is that static?
AFAIR it is static, but experts should know better.
That would explain why the RAM crashes when the device is idle and the RAM controller drops the memory clock. It might be possible to turn DLL off before power save and re-enabling it when going back to full clock rate but it could be risky if that causes bus glitches during retraining/resync. DDR RAM is always a pain to get stable.
Well, DLL should be automatically disabled on self-refresh anyways (based on the Jedec doc), but maybe the RAM freezes when DLL is being enabled again...
Or has a hickup while trying to lock again.
It still means to me: If we disable DLL, then self-refresh should still work - and unless we don't run into any issues when using the RAM normally with DLL switched off, we shouldn't have any downsides, or should we?
As DLL becomes more important the faster the RAM clock is: 532MHz isn't that fast (DDR3 supports way higher clock rates) which is the reason DLL off works fine...?
I have thought a little about the key purpose of the DLL - it is to compensate for different wiring lengths between clocks and data lines, especially on bigger DDR3 DIMMs for PCs. There, each DRAM can have a different distance from the connector and hence a different delay, especially if there are 8 or 16 chips on one board, there may be some cm. Each m distance on some PCB means roughly 10 ns delay. So a memory board with 5cm length can have 500ps delay between both ends which is a lot for a 1GHz signal (half sine wave). And this is compensated by the DLL.
But our CPU bord has a much nearer connection of at most 2cm and mostly parallel data and clock lines to each chip. So this could be the reason why the DLL doesn't seem to be ultimately necessary.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel