video: sunxi: don't silently change any 16bpp video mode to ARGB1555

Even in spite of having fb0_format/fb1_format configured to any of
16bpp choices (ARGB1555, ARGB1555, RGBA5551, ARGB4444, RGB655, RGB565,
RGB556) in *.fex file, it was getting silently overrided with ARGB1555.

But RGB565 is generally best supported in software and has more
performance optimizations. It would be a shame if we could not use it.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Jari Helaakoski <tekkuli@gmail.com>
video: sunxi: fix green text in RGB565 framebuffer console

When the framebuffer is configured to use RGB565 format, the default
text color was showing up green instead of gray. This was caused by
incorrectly taking low bits instead of high bits when reducing color
components from 8 bits to anything lower.

=== before ===
[   42.610000] Fb_setcolreg,regno= 7,a=FF,r=AA,g=AA,b=AA, result=0000554A
                    (0x554A = 01010 101010 01010)

=== after ===
[   37.260000] Fb_setcolreg,regno= 7,a=FF,r=AA,g=AA,b=AA, result=0000AD55
                    (0xAD55 = 10101 101010 10101)

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Jari Helaakoski <tekkuli@gmail.com>
sunxi-usb: restore usb-manager's ability to enable/disable host controllers

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: Jari Helaakoski <tekkuli@gmail.com>
HACK: sunxi: video: change kernel framebuffer mapping to writecombine

The kernelspace mapping of framebuffer (needed for fbcon) had CPU
caching enabled by some mistake. This caused glitches and artefacts
in the framebuffer console, which can be easily reproduced as reported
on IRC:

  <buZz> supereasy to reproduce;
         1) type a multiword command on (fbdev) console
         2) ctrl-left a word
         3) delete its first character
         4) tada, sticky pixels

The solution is to change the kernel framebuffer memory mapping to
writecombine, just like it is done for the userspace mapping.

This patch is definitely *not* a clean solution. It is cutting some
corners by doing exactly what was NAK'ed by the ARM kernel maintainers:
    http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/048844.html
    http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/052233.html

But the correct solution seems to be rather invasive, and I abandoned
my attempt at implementing it. In the end, we may want to switch to
CMA and/or dma_alloc_writecombine() for all these memory buffers
and drop the legacy code.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-By: Luc Verhaegen <libv@skynet.be>