misc:sun4i-gpio: remove "ugly" obsolete non-gpiolib gpio driver

Signed-off-by: Alejandro Mery <amery@geeks.cl>
sun4i-ts: Simplify code significantly

The sun4i-ts controller is capable of detecting a second touch, but when a
second touch is present then the accuracy becomes so bad the reported touch
location is not useable.

The android driver contains some complicated heuristics using the aprox.
distance between the 2 touches to see if the user is making a pinch open /
close movement, and then reports emulated multi-touch events around the last
single touch coordinate (as the dual-touch coordinates are worthless).

Note that this pinch emulation has never worked as the implementation of
the evdev mt protocol inside the android code is wrong, more over it is
wrong because there is a lot more to multi-touch then just pinch detection,
and reporting being mt capable when we're really not will confuse apps.

I'm currently writing a new rtp driver from scratch for upstream, I've decided
to start with gutting all the heuristics from the 3.4 driver making it work
the same way as I intend the upstream driver to work, so I can test things
on a kernel where I have a working lcd driver.

So this commit removes all the broken heuristics. As a bonus after this patch
the tslib.patch people have been using also is no longer needed:
https://raw.github.com/webconn/OLINUXINO/master/SOFTWARE/A13/TOUCHSCREEN/tslib.patch

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: mali: Fix UMP on systems with 2 GiB of RAM (phys->bus issue)

The mali driver has some code for converting between physical addresses
and bus addresses (they call them "cpu physical addresses" and "physical
addresses" respectively). For OS memory allocation, this delta is configured
in the "cpu_usage_adjust" variable, as can be seen in the mali driver code.

But in addition to OS memory allocation, mali also handles external memory
wrapping and UMP memory wrapping. The physical/bus addresses translation
is done separately for each type of memory in the mali driver. The older
commit from Huang Benn updated the mali code to do physical->bus addresses
translation for OS memory and external memory, but did not address a
similar issue with UMP memory. Incorrectly working UMP results in black
windows for EGL/GLES applications (and also in memory corruption) on
the systems with 2 GiB of RAM when used with X11 mali drivers:
    https://github.com/ssvb/xf86-video-fbturbo/issues/27

This patch tries to do the physical->bus addresses translation for
both external and UMP memory a bit lower in the call chain (in the
"mali_allocation_engine_map_physical" function). That's just because
the old "uk_args.phys_addr = __phys_to_bus(uk_args.phys_addr)" code
does not look nice (the "phys_addr" variable name becomes somewhat
misleading and ambiguous).

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
sunxi: Simplify and unify the __phys_to_bus/__bus_to_phys macros

These macros are used to convert between physical addresses (as
seen by the CPU) and bus addresses (as seen by various peripherals
such as the display controller, cedar, g2d, mali, ...).

The difference between physical and bus addresses is 0x40000000,
because that's the physical address of SDRAM (and PHYS_OFFSET
define in the kernel).

Huang Benn has provided an explanation earlier:
    http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/2827
But some additional demystification might be useful.

Basically, when we write an address to some hardware register of
the display controller, it is expected to be a bus address.
However as long as the size of RAM is just 1 GiB or less, adding
or subtracting a multiple of PHYS_OFFSET (which happens to be
1 GiB) to this address does not have any adverse effects. We just
get some garbage in the high address lines on the memory interface,
but these high address lines are not connected anywhere and have
no effect. So using either bus addresses or just physical
addresses was fine for the systems with 1 GiB of RAM or less.

But when having 2 GiB of RAM, using proper bus addresses becomes
really important. A failure to do so and an incorrect value in
the high address bit results in memory accesses going to a low
or high 1 GiB part of DRAM based on the value of this bit.

This behaviour is expected to be the same for all sunxi hardware
with 2 GiB of RAM. There is nothing sun7i specific in it and it
makes sense to treat sun4i/sun5i/sun7i in the same way. Also the
conversion between bus and physical addresses is a simple addition
or subtraction of PHYS_OFFSET without any need for convoluted logic.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
sunxi: Make ROOT_NFS usable out of the box on sun4i and sun7i

Tweak the defconfigs to enable relevant options. And also set
SoC-dependent LOCALVERSION identifiers, so that sun4i and sun7i
modules do not clash if installed on the same rootfs (which may
otherwise naturally happen in the case if multiple devices are
sharing the same NFS root).

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