G2D: Implement an area threshold for using G2D blits.

Due to the overhead of G2D for small screen-to-screen blits, CPU blits
are faster for small areas. This patch introduces are threshold below
which CPU blits are triggered. It is currently set to 1000 for 32bpp
and 2500 for 16bpp based on test results.

Some benchmarks:

1920x1080x16bppx60Hz, ShadowFB disabled:

x11perf -scroll10

Before:
1500000 trep @   0.0239 msec ( 41800.0/sec): Scroll 10x10 pixels
After:
2500000 trep @   0.0110 msec ( 90900.0/sec): Scroll 10x10 pixels

x11perf -copywinwin10

Before:
1200000 trep @   0.0247 msec ( 40500.0/sec): Copy 10x10 from window to window
After:
1800000 trep @   0.0146 msec ( 68600.0/sec): Copy 10x10 from window to window

Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>
G2D: Implement "double speed" 16bpp blits

When source and destination coordinates allow it, a 16bpp screen-to-
screen blit is divided into up to three segments: two optional one
pixel wide edges and an  aligned middle segment that is copied in
32-bit mode.

This patch adds the low-level function sunxi_g2d_blit_r5g6b5_in_three
and adds logic to the general blit function to use it for 16bpp to
16bpp blits if the source and destination coordinates allow it. This
patch automatically enables the use of this optimization in the
sunxi G2D X driver. The area threshold for using G2D for
16bpp-to-16bpp blits was introduced in a previous patch.

Benchmarks:

1920x1080x16bpp@60Hz, ShadowFB disabled:

x11perf -scroll100
Before:
 350000 trep @   0.0881 msec ( 11400.0/sec): Scroll 100x100 pixels
After:
 350000 trep @   0.0819 msec ( 12200.0/sec): Scroll 100x100 pixels

x11perf -scroll500
Before:
  20000 trep @   1.3547 msec (   738.0/sec): Scroll 500x500 pixels
After:
  35000 trep @   0.8005 msec (  1250.0/sec): Scroll 500x500 pixels

Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>
CPU: add ARM memcpy assembly function

This is my old ARM9E/ARM11 memcpy code from
    https://garage.maemo.org/projects/mplayer/
with some tuning for Raspberry Pi (aligned prefetch added).

Will be used by VFP optimized overlapped blt function.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
CPU: Added ARM VFP two-pass overlapped blit implementation

Using VFP, we can load up to 128 bytes with a single VLDM instruction.
But before this patch, only NEON implementation was available. Just
because it showed better results on Allwinner A10 compared to VFP.
And this DDX driver used to primarily target just sunxi hardware.

But looks like it makes sense to also target other devices (at least
ODROID-X, which has the same Mali400 GPU and can use the same DRI2
integration for EGL and GLESv2 support). And on the other ARM devices,
VFP aligned reads generally work better than NEON. The benchmark
results are listed below:

            1280x720, 32bpp, testing "x11perf -scroll500"

== Exynos 5250, Cortex-A15, Non-cacheable streaming enhancement disabled ==

NEON : 10000 trep @   3.7101 msec (   270.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   2.6678 msec (   375.0/sec): Scroll 500x500 pixels

== Exynos 5250, Cortex-A15, Non-cacheable streaming enhancement enabled ==

NEON : 15000 trep @   2.2568 msec (   443.0/sec): Scroll 500x500 pixels
VFP  : 15000 trep @   2.3016 msec (   434.0/sec): Scroll 500x500 pixels

== Exynos 4412, Cortex-A9 ==

NEON : 10000 trep @   4.5125 msec (   222.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   2.7015 msec (   370.0/sec): Scroll 500x500 pixels

== TI DM3730, Cortex-A8 ==

NEON : 15000 trep @   2.2303 msec (   448.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   3.0670 msec (   326.0/sec): Scroll 500x500 pixels

== Allwinner A10, Cortex-A8 ==

NEON : 10000 trep @   2.5559 msec (   391.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   3.0580 msec (   327.0/sec): Scroll 500x500 pixels

== Raspberry Pi, BCM2708, ARM1176 ==

VFP  :  3000 trep @   8.7699 msec (   114.0/sec): Scroll 500x500 pixels

The benchmark numbers in this particular test setup roughly represent
memory copy bandwidth measured in MB/s (when doing overlapped blits
inside of a writecombine mapped framebuffer).

-----------------------------------------------------------------------

Note: the use of VFP two-pass overlapped copy instead of ShadowFB is
      still not enabled by default when running on Raspberry Pi
      because the performance results are not so great.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>