On Mon, 15 Oct 2018 at 18:43, Michael Mrozek EvilDragon@openpandora.org wrote:
Are we running at a dynamic DDR RAM clock speed? Or is that static?
Static. Changing the RAM clock speed is a rather delicate and involved procedure and not supported by linux currently (afaik).
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...
Given that apparently frequent transitions into and out of self-refresh make the problem worse, and DLL-disabled helps, it would suggest that the RAM may be having problems getting its DLL to lock reliably. Question then would be of course: Why? I think it would imply either issues with the ram clock it receives or issues with its power supply.
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?
The main concern is that JEDEC puts an upper limit of 125 MHz on DLL-disabled mode, and overall leaves it very poorly specified. We'd either have to get custom timing specs from the manufacturer or just experiment to find stable parameters and hope those don't turn out to be highly variable between devices.
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...?
Sounds plausible yes. The aforementioned 125MHz limit was obviously set by JEDEC in days when ram speeds were much lower overall.
Matthijs