* Grazvydas Ignotas notasas@gmail.com [181013 16:57]:
On Sat, Oct 13, 2018 at 6:45 PM Tony Lindgren tony@atomide.com wrote:
- Grazvydas Ignotas notasas@gmail.com [181011 23:20]:
Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
Oh this is a good catch, it means we've been running the memory at a way higher refresh rate than we should need to. It is also interesting that this seems to be somewhat related to the self-refresh?
This change works for me only work if EMIF_POWER_MANAGEMENT_CONTROL is disabled based on few quick experiments, so I wonder what's the relationship with higher non-standard values of EMIF_SDRAM_REFRESH_CONTROL REFRESH_RATE and self-refresh?
Well as far as I understand that field is a delay, so larger values mean it's refreshed less often = lower refresh rate. But I've noticed TRM's 15.3.4.6 states that only 13 LSB bits are used, so with that 0x40F1 becomes 0xF1, a very short period, meaning EMIF's refresh backlog will often be long. Because before entering self-refresh EMIF clears normal refresh backlog (15.3.4.4.3), it takes a lot longer until it actually does the self-refresh command and it becomes likely some actual work will arrive and self-refresh will be cancelled (I guess). With reduced number of self-refresh attempts you get some stability improvement.
It's a bit guesses/speculation but I think it explains things you see.
Yes OK makes sense to me. So I guess the conclusion is that broken self-refresh is the core problem we have somewhere. And using a non-standard refresh rate or disabling the internal dll just both happen to prevent memory from hitting self-refresh hiding the problem.
Regards,
Tony