On Thu, Oct 11, 2018 at 6:08 AM Michael Mrozek EvilDragon@openpandora.org wrote:
On Mi, 2018-10-10 at 17:15 -0700, Tony Lindgren wrote:
Hi,
interesting find. I thought self-refresh would mostly work automatic when there's no external clock to go into a power-saving mode - but it still depends on some timings.
Checking the datasheet of the RAM, there are five timings to be setup.
Two have min-values and three have max-values given, so no fixed timings... so there are some values we can test.
Additionally, there is a timing "tXSDLL" which seems to have something to do with the DLL. Description: "Exit Self Refresh to commands requiring a locked DLL"
So my guess is it sometimes hangs when it tries to exit self-refresh and we have DLL enabled?
Those timings are on page 52 of the RAM datasheet, in case you want to look for them.
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.
GraÅžvydas