drm/exynos/fimd: disable vblank irq after suspending windows in poweroff

Currently, win_disable synchronizes itself by waiting for a FIMD IRQ.
Therefore, postpone disabling vblank until after it completes.

Note this exposes a tiny race if a FIMD irq vblank irq arrives between
fimd_window_suspend() and fimd_disable_vblank().  However, since we've
just synchronized to vblank in fimd_window_suspend(), it is very very
unlikely that we would immediately get another vblank irq (we'd need to
be processing a backlog of vblank irqs that were ~16.7 ms delayed)
For more details see discussion here:
https://chromium-review.googlesource.com/#/c/183675/2/drivers/gpu/drm/exynos/exynos_drm_fimd.c

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:22959, chromium:226244
TEST=Manual on device:
 1) Hack /etc/init/ui-respawn.conf to return 0 always in under_limit()
 2) Attach external monitor to HDMI port
   export DISPLAY=:0; i=0; \
   while true; do i=$((i+1)); \
     echo "eDP  $i"; xdotool mousemove 100 100; sleep 0.5; pkill -9 X; sleep 10; \
     echo "HDMI $i"; xdotool mousemove 100 900; sleep 0.5; pkill -9 X; sleep 10; \
   done
 => No iommu FAULTS (kcrashes) while executing above loop.
TEST=suspend_stress_test --warn_fatal  w/ and w/out HDMI monitor
TEST=Manual on device:
 1) start cursor blinking at login screen
 2) powerd_dbus_suspend
 3) tap a key to wake up system
 => dmesg should not have any of:
    *ERROR* vblank wait timed out
    *ERROR* Timed out waiting for flips to complete

Change-Id: Ic15064dd303d46f258efc90b3c2d55643487ed5c
Reviewed-on: https://chromium-review.googlesource.com/186966
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: drm/exynos/fimd: Remove VIDINTCON0 read in fimd_wait_for_vblank

Reading VIDINTCON0 in fimd_wait_for_vblank was forward-ported to
cros/chromeos-3.8 in commit 7a9fe821d8492bb0198ba589b3634a19668cca22

Reading this interrupt enable register was originally added in [0] to determine
if vblank irq was currently enabled in order to know it should be
temporarily re-enable before waiting.
This check is now performed by drm_vblank_get/put().

[0] commit 44ebf1adc38fb9060ff86f53735e69ff18a84a03
    drm/exynos: enable vblank in fimd wait for vblank

In fact, this register read has no side effect, so just drop it.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=none
TEST=builds clean; w/ ui running and cursor displayed,
   kill -9 X
   => no crash

Change-Id: I10fd15673cb796942deb6ab342ff1dd43b8d2be8
Reviewed-on: https://chromium-review.googlesource.com/186963
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: fimd: parse dither_rgb_bpc once, at boot

FIMD dithering, used by exynos5420, requires "rgb_bpc" values supplied by
devicetree/platform_data.

Parse these values once at boot to confirm that they are correct, instead
of parsing at runtime every time dithering is enabled.

If correct rgb_bpc values are supplied, this change slightly optimizes
enabling FIMD dithering at runtime.

If incorrect values are supplied, we report an error just once at boot,
and do not use dithering.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:22230
TEST=Boot on snow and pit and ensure no color bands are seen on LCD
  when viewing:
  http://mrpimpidea.files.wordpress.com/2011/07/00l4by-36432284.jpg

Change-Id: I15171b263724aad48e4b5013b9c06e94172bf8bc
Reviewed-on: https://chromium-review.googlesource.com/176621
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: drm/exynos: only enable MIE when required

exynos5250 uses MIE for dithering.
exynos5420 uses FIMD's built-in dithering.
There is a dt-binding that the driver uses to select one or the other
dithering method.

So, if not using MIE for dithering, don't map its registers, and don't
enable/disable it during FIMD poweron/poweroff.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:11072, chrome-os-partner:22042
TEST=Boot on snow and pit and ensure no color bands are seen on LCD
  when viewing a gradation test image

Change-Id: Ibfe22e53477baea45f0677d81b89e7ea16641b9b
Reviewed-on: https://chromium-review.googlesource.com/175715
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: fimd: set dithering during commit not win_commit

Dithering applies to the entire FIMD output, so can be configured when
doing a full mode set, not when doing a "window" mode set.

In other words, there is no need to do the dithering configuration on
every pageflip.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:22042
TEST=Boot on snow and pit and ensure no color bands are seen on LCD
  when viewing a gradient such as:
  http://mrpimpidea.files.wordpress.com/2011/07/00l4by-36432284.jpg

Change-Id: I2cf3087a5e0e61b0694099c06793de3a99bf4a0d
Reviewed-on: https://chromium-review.googlesource.com/177317
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: fimd: parse the timing register offset, at boot

FIMD has a main set of registers pointed to by ctx->regs.
There is a second set of timing registers whose offset from the first
group varies by platform.

This offset is stored in the struct fimd_driver_data, which is stashed
in platform_driver private data, or in devicetree.

Instead of constantly fetching the platform data - and even worse, calling
of_match_device - on every mode set, just do this once during
probe and cache the timing register base address in ctx.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=none
TEST=builds clean

Change-Id: I17b4b6f0e7c4a1d27acfe2798d792aacc7d7894e
Reviewed-on: https://chromium-review.googlesource.com/177318
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: fimd: correct timing porch conversion

In this patch porch is calculated in compatible way to
drm_display_mode_from_videomode core function.
The way it was seems to me incorrect and it did not work on my hw.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

From: http://lists.freedesktop.org/archives/dri-devel/2014-January/052441.html
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=none
TEST=builds clean; sanity check FIMD panel on daisy

Change-Id: I87f44344a52c6828b1e6bc1dfd9078ec369bdabe
Reviewed-on: https://chromium-review.googlesource.com/186876
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: constify manager and display ops

Function tables like this are usually const.

Note: vidi is not updated, since it looks like it is totally broken by
now anyway.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=none
TEST=builds clean

Change-Id: Ib37017bd76d94a7feccaab590b6d8886032dd64b
Reviewed-on: https://chromium-review.googlesource.com/186877
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm/exynos: constify drm_ funcs and display ops

Function tables like this are usually const.

The only exception is drm_fb_helper_funcs, which is a lingering const
correctness bug in drm_fb_helper.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=none
TEST=builds clean

Change-Id: I7dc0046fa5d709b139e127da6b5d2d706a30a69f
Reviewed-on: https://chromium-review.googlesource.com/186878
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
drm: exynos: Add powerup/down routines for eDP panel

Add powerup and powerdown routines for eDP panel,
and integrate the same with the exynos DP driver.

The panel powerup/down routines can be used to set all related GPIO
and regulator settings for the eDP panel, like:
--regulator fet for LCD
--regulator fet for LED
--LCD_EN signal
--BL_EN signal
--Delay needed for complete powerup
--Delay needed for complete powerdown

The above settings required for panel powerup/down can be added
via DP DT bindings.

BUG=chrome-os-partner:24914, chrome-os-partner:24672,
    chrome-os-partner:25567
TEST=Boot an peach-pi and pit.
     Check for smooth display transitions during bootup, DPMS and S2R calls.
     Also, on peach-pi, observe that the FET for LCD and LED are down
     during DPMS_OFF using the following commands:
     i2cget -f -y 20 0x48 0x0f => 0x0e
     i2cget -f -y 20 0x48 0x14 => 0x0e

Change-Id: Ie9223a0543fa053690b6d56f0e162b3d5087fb0c
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/182454
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Jaehoon Kim <jh228.kim@samsung.com>
Tested-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
arm: dts: exynos542x: Add DP panel powerup/down settings for pi

Add DP bindings required to control eDP panel powerup
and powerdown sequence.
With this patch, we need not keep FET1 and FET6 "always-on" anymore.
Removing the setting for the same.

BUG=chrome-os-partner:24914, chrome-os-partner:24672,
    chrome-os-partner:25567
TEST=Boot an peach-pi. Check for smooth display transitions
     during bootup, DPMS and S2R calls.
     Also, observe that the FET for LCD and LED are down during
     DPMS_OFF using the following commands:
     i2cget -f -y 20 0x48 0x0f => 0x0e
     i2cget -f -y 20 0x48 0x14 => 0x0e

Change-Id: I84dde30207c27fe7f490d06f671426a6a31781ab
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/182455
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
Revert "Exynos542x: dts: Turn FET5 off when system is in suspend mode"

This reverts commit ec3f1c80683272cce57786520ceb66a3cedc6c8b.

We're getting suspend/resume problems, so revert until we
can get to the bottom of things.

BUG=chrome-os-partner:26000
TEST=suspend_stress_test

Change-Id: I4f73f7c0eb4129570892907abbf48149fdb33000
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187073
Commit-Queue: David James <davidjames@chromium.org>
iio: isl29018: Add support for enabling/disabling vcc

We will enable vcc when the light sensor is on and not suspended.

BUG=chrome-os-partner:26000
TEST=See I5fb26191a14655d8397de156db5a20b20cf6f1c9

Change-Id: I0f43c99dad877d7de98007b726623a64bc7606ac
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187113
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
ARM: dts: Assign FET5 as the vcc for the light sensor

We'd like FET5 to get powered off while the device is suspended.
Assign it as the vcc for the light sensor so it will power on at
bootup and power off during suspend.

NOTE: Technically FET5 actually powers on _both_ the camera and the
light sensor, so we really ought to assign this as vcc to both
components.  Unfortunately there's no clean place to list the camera's
vcc since it's a USB device.  However, having the camera lose power at
the exact same time as the light sensor isn't terrible, so we'll just
do that.

BUG=chrome-os-partner:26000
TEST=On pit EC console type "pmu" while suspended and see 0x13=0x02
TEST=No problems / warnings booting snow/pit.
TEST=No problems / warnings suspend_stress_test on snow/pit.
TEST=Light sensor works on snow/pit before/after s2r.
TEST=Camera works on snow/pit before/after s2r.

Change-Id: I5fb26191a14655d8397de156db5a20b20cf6f1c9
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187114
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
UPSTREAM: net: usb: Add HP hs2434 device to ZLP exception table

This patch adds another entry (HP hs2434 Mobile Broadband) to the list
of exceptional devices that require a zero length packet in order to
function properly. This list was added in commit 844e88f0. The hs2434
is manufactured by Sierra Wireless, who also produces the MC7710,
which the ZLP exception list was created for in the first place. So
hopefully it is just this one producer's devices that will need this
workaround.

Tested on a DM1-4310NR HP notebook, which does not function without this
change.

Signed-off-by: Rob Gardner <robmatic@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 03803a59e32453ee5737c6096a295f748f03cc49)

BUG=chromium:326559
TEST=Tested the following:
1. `emerge-peppy chromeos-kernel-next`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I33e784a6083bd699d0cf0bf39a99519721c3db9c
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187013
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: net: cdc_mbim: change the default to send ZLPs

A number of devices in the wild have turned out to require ZLPs.
Even if this is a spec violation, our priority is to make any
device work as good as possible. Devices needing ZLPs will fail
to receive any full sized frame we send. On the other hand,
devices which do not need the ZLP will still work if we send
them.

This gives us no other option than sending ZLPs by default.

This will prevent devices conforming to the spec from making the
optimizations which are possible without ZLPs.  Adding known
such devices to a whitelist, to avoid the possible negative
impact of the new spec violating default.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c1a2e95435976cb040db1f6c0afbe4287c3d2e28)

BUG=chromium:326559
TEST=Tested the following:
1. `emerge-peppy chromeos-kernel-next`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I7844053d3fc68c14dde057a73900ec54f69d4d2a
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187014
Reviewed-by: Paul Stewart <pstew@chromium.org>
ARM: dts: Mark spring and skate WiFi as SDR50

On kernel 3.4 we were always using SDR50 WiFi speeds on Spring but
nobody ever quite tracked down why (the kernel always reported that we
were using slower speeds).  On kernel 3.8 the happy accident seems to
have gone away.

Now that the kernel has support for SDR50 we will tag it properly.

BUG=chromium:342094
TEST=Run throughput tests; run stability tests

Change-Id: I6b2eedc2b5c14e3fdc42d0b47c7002e66c4b2e57
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186415
Reviewed-by: Grant Grundler <grundler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: s5p-mfc: add variants to access mfc registers

This patch is needed in preparation to add MFC V8
where the register offsets are changed w.r.t MFC V6/V7.

This patch adds variants of MFC V6 and V7 while
accessing MFC registers. To do this, initialize
registers to a particular MFC variant during probe
itself, and use this set of registers.

This avoids duplication of the code for MFC variants
V6 & V7, and reduces the if_else checks while accessing
registers of different MFC variants.

BUG=chrome-os-partner:25172
TEST=Build and booted on pit and snow,
1) vdau, evea tested for vp8 and h264 on pit
2) vdau tested for vp8 & h264, veau tested for h264 on snow
3) Played multi-instance videos in browser
4) tested resolution changes in youtube.

Change-Id: I2d127bea289562c30f4e5120430764c5ca74385f
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
[posciak@chromium.org: Minor cleanup and added shortcut macros.]
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183793
Reviewed-by: Doug Anderson <dianders@chromium.org>
CHROMIUM: s5p-mfc: core support to add v8 decoder

This patch adds variant data and core support for
V8 decoder. This patch also adds the register definition
file for new firmware version v8 for MFC.

BUG=chrome-os-partner:25172
TEST=built for pi,
1)tested vdau for h264 & vp8 streams
2)tested browser video playback for multi-instance

Change-Id: Ie1813bb2d94bb57e57a44a7c6b7a1e6ac6357052
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
[posciak@chromium.org: Minor cleanup and added shortcut macros.]
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183794
Reviewed-by: Doug Anderson <dianders@chromium.org>
CHROMIUM: s5p-mfc: keep RISC ON during reset for V7/V8

Reset sequence for MFC V7 and V8 do not need RISC_ON
to be set to 0, while for MFC V6 it is still needed.

Also, remove a couple of register settings during Reset
which are not needed from V6 onwards.

BUG=chrome-os-partner:25172
TEST=vdau, s2R tested on pit & pi

Change-Id: I6f09d9d38c13e807f3eec40a22d8a90ed1d9d391
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183237
Reviewed-by: Arun Kumar <arun.kk@samsung.com>
Tested-by: Arun Kumar <arun.kk@samsung.com>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>