I'm helping a client who has a custom, battery powered device using the combination of i.MX6SL and DDR3L (Micron MT41K128M16JT).
Things work pretty well in normal circumstances, but start to go haywire during suspend, where the BSP doesn't seem to support this combination. In particular, we've found that there are places like this bit in busfreq-imx.c that assume that only LPDDR2 is used on the Solo Lite:
} else if (cpu_is_imx6sl()) { err = init_mmdc_lpddr2_settings(pdev); }
Fixing that (patch 1) shows that busfreq_ddr3.c also needs an update to support i.MX6SL (patch 2).
Even with these two patches, suspend/resume results in a system reset though.
Looking at pm-imx6.c shows that the MMDC registers aren't saved and restored in suspend and resume (mmdc_num/mmdc_offset), but some other processor variants also omit this, and I'm not seeing a pattern that this is a function of the type of memory.
Updating the i.MX6SL to match the structure of the i.MX6SX (patch 3) doesn't address the problem, and we're stuck with a machine that resets (via watchdog) upon resume.
The fact that U-Boot reports a WDOG reset is puzzling. This occurs even if the Linux watchdog driver is disabled, and appears to come from the mxc_restart routine (commenting it out results in a system that hangs instead of resetting). Since this routine isn't part of the code copied to IRAM during suspend-to-mem, it appears the DDR must be staying valid through the suspend process.
Okay, so on to the actual questions:
N.B.: we also tried using a mainline kernel, which has a dramatically different code structure and got the same result (reset via watchdog).
Hello,
According to the app team, the patches, mentioned here (above), are enough.
Please try to merge all the necessary patches carefully to get working system.
Regards,
Yuri.
Thanks very much, Yuri.