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 artifacts
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

The ioremap restriction (intended to prevent creating aliased mappings
with different memory attributes) has been introduced with 309caa9cc6ff39d2,
later relaxed in 06c10884486a63a1, and finally re-introduced again
in 67cfa23ac9df810d.

Even though this patch is not perfect, it can be used as a stopgap solution.

= changes in v2 revision:
    Fix for the problems with disp module loading/unloading in dual-monitor
    configuration. Added debugging messages and fallback code for the case
    if ioremap_wc() fails.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
arm:mach-sun4i:clock: Fix for "[ccmu] try to set apb1 parent to sata_pll failed!" warning print. U-boot also uses OSC24M for apb1.
tty:serial:8250_sunxi: Fix module unload
sunxi-serial: Fix bad pointer access in sw_serial_pm

The sunxi-serial code assumes that the struct uart_port *port parameter
passed to the pm callback it the address of the struct it used to register.

But this is completely wrong! The argument passed to serial8250_register_port
is only a template, it is copied not used directly. Instead store the
correct address in port->private_data and use that.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-serial: No need to keep the port struct in memory

Since it is only a template we don't need to keep it around.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-serial: Get rid of sw_serial global array

There is no need for global state here, instead store the line-number we
got from registering together with our other info in the sw_serial_port
struct.

While at it, also add proper error checking for the serial8250_register_port
call.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-serial: Get rid of useless sw_serial_get_config

All info gathered there is never uses, so while we're cleaning up the
sunxi-serial code lets nuke this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
input:touchscreen:ft5x_ts: Make device visible under /sys/class/input/input*
arch:arm:configs add ext4 fs capabilities

add ext4 fs capabilities to defconfigs.

this allows fedora 17 packages to be updated as rpm uses capabilities
in preference to setuid.

Signed-off-by: Robin Humble <robin.humble+sunxi@anu.edu.au>
sunxi: disp_ump: Introduce a new ioctl for UMP wrapping the whole framebuffer

There are two ioctls (GET_UMP_SECURE_ID_BUF1 and GET_UMP_SECURE_ID_BUF2)
available for similar purpose already. And they are used by xf86-video-mali
X11 DDX driver.

In order not to clash with them, we just can add a new ioctl. This ioctl is
needed for the new, soon to be announced xf86-video-sunxifb X11 DDX driver.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
video:sunxi:disp:Dynamic mode switching

This patch improves Hans De Goede's EDID patch by allowing user to set new mode at runtime.
Example: echo D:1280x720p-60 > /sys/devices/platform/disp/graphics/fb0/mode
But precondition is that EDID support must be activated like before.
Ie. by using following modprobe configuration:
options disp screen0_output_mode=EDID:1280x720p60

Signed-off-by: Jari Helaakoski <tekkuli@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
video:sunxi:disp:Use BSP_disp_get_videomode elsewhere.

Double buffering must be always on, or it can cause performance problems in gles applications.

Signed-off-by: Jari Helaakoski <tekkuli@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
video:sunxi:disp:Remove struct __disp_tcon_timing_t

Cleanup.

Signed-off-by: Jari Helaakoski <tekkuli@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
video:sunxi:disp:Make Fb_Init export cleaner

Cleanup

Signed-off-by: Jari Helaakoski <tekkuli@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
sunxi-hdmi: Replace some magic constants with defines

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-hdmi: Don't overwrite the current timings when receiving new EDID

Besides that overwriting the current timings is just wrong, this also
fixes a lot of "EDID mode used without valid EDID info" messages getting
thrown and more nasty side effects when unplugging and replugging a monitor.

What was happening is that the hdmi-edid code calls hdmi_edid_received,
which updates the fb_dev mode-list, the fbdev core code responds to this
by asking us what the current mode is, which ends up with a call to
hdmi_get_video_timing(). which would fail in Hdmi_tv_mode_to_hdmi_mode
because the Device_Support_VIC[HDMI_EDID] has been set to 0.

After the fbdev core failed to get the current mode, it tries to set things
to a new mode, which ends up doing a hdmi_get_video_timing() again (to
save the current mode as a fallback in case the new mode fails), which fails,
and things go downhill from there...

This patches fixes all this by keeping the current timing info in place as
*the* EDID mode when the current video_mode is HDMI_EDID.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-hdmi: Call hdmi_edid_received after checking the checksum

As it is not really helpful to pass bogus data to the fbdev ...

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-hdmi: Fix some modes no longer working with X

The "video:sunxi:disp:Dynamic mode switching" patch adds a check to
see if the passed in pixelclock is valid when calling Fb_check_var.

However that pixelclock gets there through a KHZ2PICOS followed by a
PICOS2KHZ conversion, changing for example a 85500000 clock into a
85506000 clock, causing this check to fail.

Note that the inaccuracy in this conversion is such, that it will fail
for almost any mode, yet for some reason this seems to only cause
problems for some modes. One theory I've is that a 85500000 mode causes
problems with X, because X only makes the (now failing) FBIOPUT_VSCREENINFO
call when KHZ2PICOS followed by PICOS2KHZ leads to a difference of
more then .01 Mhz after rounding. IE xorg.log for the failed case contains:
FBDEV(0):  Built-in mode "current": 85.5 MHz, 47.7 kHz, 60.0 Hz
FBDEV(0): Modeline "current"x0.0   85.51  1360 1424 1536 1792 ...
Note the 85.51 versus 85.5. In the end it does not matter, since we
simply need to deal with the inaccuracy and not make Fb_check_var
fail because of it.

This patch fixes this by:
1) Introducing new PICOS2HZ and HZ2PICOS inline functions (named in caps
   to match the naming of the PICOS2KHZ and KHZ2PICOS macros, but these
   cannot be macros because they need 64 bit divisions).

   This greatly improves accuracy since we have all clocks in HZ and converting
   them to Khz first just throws away a lot of precision
2) Rounding the result of PICOS2HZ to the nearest multiple of 10000 since edid
   clocks are always a multiple of 10000

Concretely this fixes X no longer starting on my HD ready television.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-configs: minimalize configs with savedefconfig

defconfig files should be saved with "make savedefconfig".

It has been fixed with this command:
>    for config in $(grep -rl 'Automatically generated' arch/arm/configs);
>    do
>        cp $config .config;
>        make ARCH=arm savedefconfig;
>        mv defconfig $config; rm .config;
>    done

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
leds:sunxi: Added LEDS driver for sunxi platforms

Signed-off-by: Alexandr V. Shutko <alex@shutko.ru>