On Fr, 2018-11-02 at 02:55 +0100, Matthijs van Duin wrote:
Hi,
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).
Ah, okay. Does that mean that self-refresh also doesn't lower the clock rate?
Is Android different here?
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.
I think we can rule out the power supply, as the memory runs fine whatever you do when DLL is off, and even when DLL is on as long as you run a memtester and keep the memory busy.
Unless you mean that the power supply has issues keeping the power constant when the memory usage changes but that would be the PALMAS and that handles it automatically.
Also, 2GB RAM doesn't have the issue, and the power consumption is nearly the same.
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 far as I understood from the JEDEC documents, DLL doesn't have anything to do with the timing settings - we've already set up the custom timings according to the datasheet.
If I understood correctly, DLL is being used to automatically compensate timing issues caused by longer traces (higher resistance values). A Dual-Die RAM could otherwise receive or transfer the requested value from the wrong chip.
However, if it works fine without DLL, then it seems our traces / resistances are good enough for the timings..?
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.
Okay. BTW: Where did you find thoese 125MHz limit? I've checked the full JEDEC documentation, but didn't find anything about that (or a limit value for DLL)