Bugfix for 1080p support on modern EDID >=1.3 screens

For official kernel patch:
https://patchwork.kernel.org/patch/1102172/

For more info:
http://http://hwswbits.blogspot.com/2013/03/bugfix-for-wrong-monitor-resolution-in.html
Bugfix sram_gpio_init for RK3066 when called for RK30_PIN6_*

sram_gpio_init is called from mach-rk30/board-pmu-tps65910.c with
PMU_POWER_SLEEP (RK30_PIN6_PB1) as first argument. The return is -EINVAL
even though it's a valid pin.

This is caused, in rk3066, by the bad way in which sram_gpio_init checks
against the gpio_base array, taking into account that for RK3066 this
array is missing one element (RK30_GPIO5_BASE, which is ok). This makes
it give wrong results for any pin on GPIO6_BASE, because of this
comparison:
       if(index/NUM_GROUP >= ARRAY_SIZE(gpio_base))

For example:
PMU_POWER_SLEEP = RK30_PIN6_PB1 = 361

Taking the previous line's index calc: index = gpio - PIN_BASE;
Knowing that:
- #define PIN_BASE         NR_GIC_IRQS
- #define NR_GIC_IRQS      (5 * 32)

index = gpio - PIN_BASE = 361 - 5*32 = 201

and then in the if we have:
-  index/NUM_GROUP = 201 / 32 = 6.2 ... = 6
-  ARRAY_SIZE(gpio_base) = 6

which is == to ARRAY_SIZE so RK30_PIN6_* fail here
due to using array_size without a RK30_GPIO5_BASE

Solution entails failing on pins in GPIO5_BASE, but allowing them in
GPIO6, and then pressing the right base into data->base by using index 5
for GPIO6, as expected.
phjanderson (freaktab) video fix

In rk3188_lcdc.c is a handler for vsync interrupts:
   static irqreturn_t rk3188_lcdc_isr(intirq,void*dev_id)
Basically this code triggers all the listeners for vsync events
(vsync_info.wait). rk_fb.c hooks into this event:
   static int rk_fb_wait_for_vsync_thread(void*data)
Basically this function starts a thread that listens to the vsync events
and publishes those to the system (sysfs_notify).
Now look at this particular line (this commit's diff)

It says: wait for the vsync event, but the condition needs to be
!ktime_equal(timestamp, dev_drv->vsync_info.timestamp) && dev_drv-
>vsync_info.active. The last bit is to see if the vsync thread is
running, the first part however... no clue. Seems to me some kind of
workaround to prevent the vsync event to be accidentally triggered twice
for the same vsync. I removed !ktime_equal(timestamp, dev_drv-
>vsync_info.timestamp) && part from that line and tried to play a video:
perfectly smooth!

Reference:
http://www.freaktab.com/showthread.php?5939-Fixing-RK3188-video-playback&p=81489&viewfull=1#post81489
Merge pull request #1 from Galland/master

Bugfix for 1080p support on modern EDID >=1.3 screens