* Michael Mrozek EvilDragon@openpandora.org [181012 02:23]:
On Fr, 2018-10-12 at 02:41 +0300, Grazvydas Ignotas wrote:
Do you know if disabling self-refresh has any negative side effects? Would it increase power consumption a lot or probably not really noticeable?
It will increase the idle power consumption quite a bit AFAIK, this is a sign of something being broken for sure.
I've gone through all of them, and the ones that are programmable are correctly programmed already. There were minor mistakes (patches sent) but fixing them has no effect on the hang issue. Things I tried:
- higher cl values
- more relaxed / higher other timings that are programmable
- dumping registers from Linux and confirming everything is
programmed as it should be
- overclocking to 533.7MHz (not sure if exact 533 can be achieved
because of how omap's dpll works)
- other things I forgot
Among things not tried are strange registers like CONTROL_DDR3CH2_0 CONTROL_EMIF1_SDRAM_CONFIG_EXT - it's hard to understand what they do and how they could help with our issue.
The only thing that helps besides DLL disable is disabling self-refresh. I think the RAMs are incompatible with how OMAP5 does power saving, that's all there is to it. We'll have to choose one of those workarounds. Probably disabling self-refresh makes the most sense since unlike the DLL option it's not against any specs or requirements.
These are my findings as well, I was not able to find anything that would make things better or worse regarding the self refresh issue other than disable self refresh or disable internal dll like Grazvydas listed. Timing value changes for tRFC and tXSDLL don't seem to make a difference.
My gut feeling is it's some kind of signaling issue occasionally causing the relocking the of the ddr internal dll to fail. The only difference compared to other omap5 and dra7 devices is the use of two chip selects on Pyra 4GB.
But for developer devices and testing, yeah disabling memory self-refresh is the way to go.
Regards,
Tony