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>
mach-sunxi: configure IRQ for ARM Cortex-A8 performance monitoring unit

This allows the use of performance monitoring unit for statistical
sampling based profiling (oprofile, perf).

The downside is that the performance unit in Cortex-A8 is affected
by erratum 628216, which causes it to miss interrupts in some cases
and disrupt profiling results. Some information in public access
about this erratum can be found here:
    http://www.freescale.com/files/32bit/doc/errata/IMX53CE.pdf

As a result, it may be preferable to keep using the standard
timer for general purpose profiling instead of the PMU cycle
counter. But some of the other performance events may be still
useful in practice (cache misses, ...).

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
block:sunxi-nand: New flash chips from i-onik.de allwinner source

I found that the i-onik sources from allwinner had an updated nand_id.c
file with settings I needed for a nand chip on a new device.  This
series of patches merges it in.  This patch adds all the new entries
that didn't exist before.

Signed-off-by: Neal Peacock <neal@nic-stix.com>
block:sunxi-nand: settings updates for various flash chips based on i-onik.de allwinner source dump

This patch updates the settings that were found to be different, note I
haven't tested all these changes.

Signed-off-by: Neal Peacock <neal@nic-stix.com>
sunxi-hdmi: Fix pixelclock conversion harder

The pixelclock in hz -> picoseconds -> hz conversions loosing precision
first fixed by "sunxi-hdmi: Fix some modes no longer working with X",
is still a problem with some modes :|

For example 130000000 becomes 130010000, and X does not work.

We can only do pixelclocks which are a divider of 1 - 15 of a multiple of
3 MHz. Combining this with EDID's granularity of 10 Khz, all clocks must have
been a multiple of 100 or 250 KHz before the conversion.

Therefore this patch changes the rounding in fb_videomode_pixclock_to_hdmi_pclk
from rounding to 10Khz to rounding to 50Khz, which should hopefullly be
enough to get rid of any imprecision introduced by the conversion process.

Reported-by: Daniel Veillard <veillard@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-disp: Fix tv-out / standard tv-modes not working

For the tv / hdmi output lcd_clk_div is not used when programming the pll,
instead pre_scale is used. My commit titled:
"sunxi-hdmi: Dynamically determine pll frequency for hdmi modes"

Wrongly sets lcd_clk_div rather then setting pre_scale. This bug did not get
noticed sofar because pre_scale gets initialized to 1, which is the correct
value for non 27000000 Hz pixelclock modes.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-disp: Add missing break

This fixes a kernel NULL ptr deref (trying to call hdmi functions before they
are registered) when trying to use tv-out.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-disp: Use mode names like pal and ntsc for specifying tv-out modes

Some of the tv modes have the exact same dimensions but are different in
things like how the color is encoded, so specifying <width>x<height> is not
enough to uniquely identify them.

Therefore this patch changes the screen0_output_mode value to be a mode-name
like pal, ntsc or pal-nc when the screen0_output_type is set to tv.

As an added bonus this patch also limits which modes from the tv_mode table
can be selected, so that the user can no longer select hdmi only modes when
using tv-out.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
axp20-mfd.h: Re-format chip init register values

So that they can be read without needing horizontal scrolling.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
axp20-mfd.h: Fixup axp20_init_chip to not cause spurious interrupts

Before this patch axp20_init_chip did the following:
1) Set the interrupt enable registers to 0x000000000103ffd8
2) Write 0xffffffffffffffff to the interrupt status registers to
   write-clear all interrupt status bits
3) Write 0x0000000000000000 to the interrupt enable registers to
   disable all interrupts

Between 2 and 3 an unwanted interrupt can trigger and since this is all
done over slow i2c there is plenty of time for this.

This patch fixes this by changing the init sequence to:
1) Set the interrupt enable registers to 0x0000000000000000
2) Write 0xffffffffffffffff to the interrupt status registers to
   write-clear all interrupt status bits

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
input:touchscreen:ft5x_ts: Enable needed bits for xorg input device probe.

[    17.888] (II) config/udev: Adding input device ft5x_ts (/dev/input/event1)
[    17.888] (**) ft5x_ts: Applying InputClass "evdev touchscreen catchall"
[    17.888] (II) Using input driver 'evdev' for 'ft5x_ts'
[    17.888] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[    17.888] (**) ft5x_ts: always reports core events
[    17.889] (**) evdev: ft5x_ts: Device: "/dev/input/event1"
[    17.889] (--) evdev: ft5x_ts: Vendor 0 Product 0
[    17.889] (--) evdev: ft5x_ts: Found absolute axes
[    17.889] (--) evdev: ft5x_ts: Found absolute multitouch axes
[    17.889] (--) evdev: ft5x_ts: Found x and y absolute axes
[    17.889] (--) evdev: ft5x_ts: Found absolute touchscreen
[    17.890] (II) evdev: ft5x_ts: Configuring as touchscreen
[    17.890] (**) evdev: ft5x_ts: YAxisMapping: buttons 4 and 5
[    17.890] (**) evdev: ft5x_ts: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[    17.890] (**) Option "config_info" "udev:/sys/devices/platform/sun4i-i2c.2/i2c-2/2-0038/input/input1/event1"
[    17.891] (II) XINPUT: Adding extended input device "ft5x_ts" (type: TOUCHSCREEN, id 7)
[    17.891] (II) evdev: ft5x_ts: initialized for absolute axes.
[    17.893] (**) ft5x_ts: (accel) keeping acceleration scheme 1
[    17.893] (**) ft5x_ts: (accel) acceleration profile 0
[    17.893] (**) ft5x_ts: (accel) acceleration factor: 2.000
[    17.893] (**) ft5x_ts: (accel) acceleration threshold: 4
[    17.895] (II) config/udev: Adding input device ft5x_ts (/dev/input/mouse0)
[    17.896] (II) No input driver specified, ignoring this device.
[    17.896] (II) This device may have been added with another device file.

Signed-off-by: Jari Helaakoski <tekkuli@gmail.com>