sunxi: dram: Adjust cubietruck dram chip width and density

Cubietruck has four 4Gb x8 DDR3 chips, not two 8Gb x16. This doesn't
change anything for users, but reports correct values for timing
parameters depending on density.

Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: dram: Fix autorefresh timing setup

This patch unifies sun4i and sun[5,7]i autorefresh setup functions
and adds proper tRFC calculation.

tRFC (REF command to ACT time) depends on DDR type and chip density.

On sun4i there were two steps, 127.5ns for <=1Gb density and 327.5ns
for the rest. This fits DDR2 specification for 1Gb and 4Gb chips
and shouldn't be a problems with DDR3 chips <8Gb either, but it will
waste some performance.

On sun[5,7]i however, tRFC was hardcoded to 131 clock cycles, which
seems to come from 4Gb DDR2 chips at 400MHz (327.5ns * 400MHz = 131).
For 4Gb DDR3 chips, like those on cubieboard2 and cubietruck, this
means the memory frequency was limited to ~435MHz if one doesn't want
to fall below the minimum specified tRFC for these chips.

Signed-off-by: Jens Kuske <jenskuske@gmail.com>
sunxi: dram: Support more DRAM clock speeds (396, 468, 496, 512, 540)

These are some additional interesting DRAM clock frequencies. And
they can be supported, while keeping the PLL5P clock speed at least
not higher than the DRAM clock speed. PLL5P output is used to
clock a lot of peripherals, so we need to be careful not to
break them (or more like some buggy code in the sunxi-3.4
kernel, which just sets hardcoded divisors in some places).

Having 396MHz is nice. It can be used with the tight DDR3-800
timings (CL-tRCD-tRP-tRAS). For comparison, moving to 408MHz
requires extra cycles for many of these timing parameters,
which results in a latency increase.

Having 512MHz and 540MHz is also useful, because they provide better
granularity of the DRAM clock frequency selection around DDR3-1066
speed. And this is an interesting DRAM overclocking target.

The extra five branches add ~120 bytes of code if compiled
for ARM and ~90 bytes of code if compiled for Thumb2.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: dram: Fix dram_tpr3 handling for sun4i

This ifdef wrapped code apparently was introduced as a unification
of sun4i/sun5i and sun7i codebases and assumed that the non-sun7i
part of it was correct. However experiments show that this 4-bit
bitfield behaves in the same way at least on sun4i and sun7i.

Also see the definition in 'include/synopsys/dwcddr21mctl.h':
    #define DWCDDR21MCTL_DLLCR_PHASE(x) (((x) & 0xf) << 14)

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: dram: Tweak DEFE port setup to fix A10 screen shaking issue

When driving a 1920x1080-32@60Hz monitor, framebuffer scanout for
screen refresh becomes more bandwidth intensive and challening.
There used to be an old problem, which manifested itself as a
screen shaking effect when CPU or GPU are doing something memory
intensive and competing for the memory bandwidth with the display
controller. A possible explanation for it is that the display
controller just sends the previous scanline over HDMI in the case
if it can't read the current one in time.

Framebuffer scanout can be done either by DEBE or by DEFE. It seems
like DEBE is broken beyond repair. Apparently it is doing isolated
32 byte burst reads at regular intervals to scan out the framebuffer
and send this data over HDMI. The size of this burst is too small.
And if something else (CPU or GPU) is accessing memory at the same
time, we easily get bank conflicts with huge penalties. As these
penalties happen per 32 bytes of data, most of the memory bandwidth
is wasted. The end result is the screen shaking effect and a
significant performance loss for the CPU/GPU. This all is happening
because DEBE is configured to have higher priority than CPU and GPU.
So it can do these tiny bursts and nobody can do anything about it.
If we reduce the priority of DEBE, then the screen shaking effect
becomes much worse.

DEFE is somewhat similar to DEBE. But the key difference is that
it seems to implement some buffering of data and this buffer does
not underrun so easily. So it is possible to drop the priority
of DEFE port and make it the same as CPU/GPU. However in order to
get really perfect results, we need to also increase the "host port
command number" parameter. It is currently set to 0x10 by default
(the same as for CPU and GPU) and from what it looks, it affects
the bandwidth distribution between the ports with equal priority.
To experiment with this, I took A10-OLinuXino-LIME board (which
has a slow 16-bit memory interface) and downclocked DRAM to 408MHz.
Then used lima-memtester and glmark2-es2 programs to reproduce the
screen shaking effect. Increasing the "host port command number"
parameter resulted in a gradual reduction of the image glitches.
And at 0x50, the shaking effect disappeared completely.

So all that we need to do is a simple change "0x1035 -> 0x5031"
for the DEFE host port setup. And even A10-OLinuXino-LIME becomes
able to drive a FullHD monitor at 60Hz and 32bpp without issues
if "fb0_scaler_mode_enable" is set to 1 in the fex file.

Additionally, for A10-OLinuXino-LIME with DRAM clocked at 480MHz
and driving a 1920x1080-32@60Hz monitor in "scaler" mode, the
memset performance improves from 559.3 MB/s to 807.3 MB/s and
the memcpy performance improves from 299.3 MB/s to 317.9 MB/s
after this patch. So the memory bandwidth drain becomes smaller
the the overall system performance improves.

This has been also discussed at:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04085.html

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: remove unbounded loops from DRAM setup.

Introduce a helper function which waits for up to 1s for the necesary bits
to clear and then panic()s.

Requested by Marek during upstream review.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>