On Fri, 2014-07-25 at 04:41 +0300, Siarhei Siamashka wrote:
On Mon, 21 Jul 2014 19:51:50 +0100 Ian Campbell ijc@hellion.org.uk wrote:
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
Before driving the CKE pin (Clock Enable) high, the DDR3 spec requires to wait for additional 500 us after the RESET pin is de-asserted.
The DRAM controller takes care of this delay by itself, using a configurable counter in the SDR_IDCR register. This works in the same way on sun4i/sun5i/sun7i hardware (even the default register value 0x00c80064 is identical). Except that the counter is ticking a bit slower on sun7i (3 DRAM clock cycles instead of 2), resulting in longer actual delays for the same settings.
This patch keeps the old code and only removes the CONFIG_SUN7I ifdef. But maybe we should drop all of this and just add 'udelay(500)' after the DDR3 reset without bothering to play with these undocumented registers.
I'm happy to go with whichever you think is better.
If the total DRAM initialization time in u-boot is not really critical (all the delays are only fractions of millisecond), then I would probably go with the "cargo cult" approach and actually apply the delays in both places ('udelay(500)' after the DDR3 reset and keep the maximum delay in the SDR_IDCR register too).
Makes sense to me.
If someone later decides they really care about boot time to this degree then they can implement the SDR_IDCR thing, hopefully with the aid of a logic analyser, as you say.
Ian.