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>