s5p-mfc: Modify encoder buffer alloc sequence

<UPSTREAM MERGE NOT REQUIRED>

MFC v6 needs minimum number of capture buffers to be queued
for encoder depending on the stream type and profile.
For achieving this the sequence for allocating buffers at
the encoder is modified similar to that of decoder.
The new sequence is as follows:

1) Set format on CAPTURE plane
2) REQBUF on CAPTURE
3) QBUFS and STREAMON on CAPTURE

This also fixes the crash happeninig during multi instance encoder-
decoder simultaneous run due to memory allocation happening from
interrupt context.

BUG=chrome-os-partner:18019
TEST=Worked with MFC unit test app [1]

[1]http://git.infradead.org/users/kmpark/public-apps

Change-Id: Ia33bbb90b41697742091ddc639de6438f0cf2cc4
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Signed-off-by: John Sheu <sheu@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56308
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
CHROMIUM: drm/bridge: ps8622: don't set backlight if bridge is off

Userspace may attempt to set the backlight while the bridge chip is disabled.
Communication with the bridge chip will fail in this case and may put the
chip in a bad state, so return an error when this happens.

Original-Change-Id: Ia63545601494e90ca7d48a64b25198c0c0fd9d6d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/37726
Commit-Queue: Andrew Bresticker <abrestic@google.com>
Reviewed-by: Andrew Bresticker <abrestic@google.com>
Tested-by: Andrew Bresticker <abrestic@google.com>
Reviewed-by: Doug Anderson <dianders@google.com>
(cherry picked from peach-alpha commit
	ec2625c2af5d9207b618362d2f3e1235a8e5380b)

BUG=chrome-os-partner:19760
TEST=Build and boot on Spring

Change-Id: I4bbbf0c1818362681345f608cb4eb6642db0d9eb
Reviewed-on: https://gerrit.chromium.org/gerrit/56598
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
CHROMIUM: usb: xhci: Use non-interruptible sleep for XHCI commands

The XHCI stack usually uses wait_for_completion_interruptible_timeout()
to wait for the completion of an XHCI command, and treats both timeouts
and interruptions as errors. This is a bad idea, since these commands
are often essential for the correct operation of the USB stack, and
their failure can leave devices in a misconfigured and/or unusable
state. While a timeout probably means a real problem that needs to be
dealt with, a random signal to the controlling user-space process should
not cause such harsh consequences.

This patch changes that behavior to use uninterruptible waits instead.
It fixes an easy to reproduce bug that occurs when you kill -9 a
process that reads from a UVC camera. The UVC driver's release code
tries to set the camera's alternate setting back to 0, but the lingering
SIGKILL instantly aborts any Stop Endpoint or Configure Endpoint command
sent to the xHC. The code dies halfway through the bandwidth allocation
process, leaving the device in an active configuration and preventing
future access to it due to the now out-of-sync bandwidth calculation.

This patch should be backported to kernels as far 2.6.31 that contain
the commit 3ffbba9511b4148cbe1f6b6238686adaeaca8feb "USB: xhci: Allocate
and address USB devices".

BUG=chrome-os-partner:19579
TEST=Do a cv2.VideoCapture(0).read() from python, then kill -9 the
python process. Make sure camera still works (on Spring or Stout).

Marking this CHROMIUM for now as it's needed to fix a factory test
problem, but I intend to upstream it immediately, too.

Change-Id: Idbef2ea30e20af854b73342a577c09757e7a542b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56555
Reviewed-by: Pawel Osciak <posciak@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: md: dm-bootcache, dm-verity, dm-verity-chromeps - support for PARTUUID

Added support for UUIDs that are labeled PARTUUID=%U[/PARTNTOFF=%d].
This is in preparation of converting to this format that
will let us delete the UUID code in these three device mappers.

BUG=chromium:224066
TEST=platform_CorruptRootfs with/without new format, bootcache on/off, verity on/off

Change-Id: I753ba957835479412fc59ff6454168915a9b3ce6
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51530
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
CHROMIUM: rtc: cmos: Workaround bios clearing rtc control

The bios may clear the rtc control register when resuming the system. Since the
cmos interrupt handler may now be run before the rtc_cmos is resumed, this can
cause the interrupt handler to ignore an alarm since the alarm bit is not set in
the rtc control register. To work around this, check if the rtc_cmos is
suspended and use the stored value for the rtc control register.

BUG=chromium:242788
TEST=power_Resume -i 50
	Make sure there are no RTC errors

Change-Id: Ib0236ab01b69d96fb673dc29ce2aef7b2fd7f440
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57131
Reviewed-by: Sameer Nanda <snanda@chromium.org>
CHROMIUM: drm/i915: Only repin the fences on resume

The previous patch repins both the fences and the gem objects on
resume, which is wrong because, unlike the fence pin count, the gem
object pin count doesn't get reset across suspend/resume.

BUG=chrome-os-partner:19059
TEST=compiles and runs

Change-Id: I6e76e197f28d889990fcd014c4c4fe745438aa35
Reviewed-on: https://gerrit.chromium.org/gerrit/57089
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
CHROMIUM: mmc: dw_mmc: add HS200 tuning feature

Add tuning feature for exynos5250. This supports HS200, UHS-I(SDR104).

This commit is loosely based on code from:
	https://android.googlesource.com/kernel/exynos
	commit-Id: 016ebd43ab27cf8b0258d1e7d3e3288d7f7aab6a

BUG=chrome-os-partner:18666
TEST=Booted on snow to login screen.
    Confirmed the eMMC 4.5 (HS200 capable) card is detected and running
    at 200MHz (kernel dmesg output):
	mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, actual 200000000HZ div = 0)
	mmc0: new HS200 MMC card at address 0001
	mmcblk0: mmc0:0001 MAG2GA 14.5 GiB
	mmcblk0boot0: mmc0:0001 MAG2GA partition 1 2.00 MiB
	mmcblk0boot1: mmc0:0001 MAG2GA partition 2 2.00 MiB
	mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
	mmcblk0boot1: unknown partition table
	mmcblk0boot0: unknown partition table

Change-Id: I8162f522e3aab902d5d68d2aca73c3cbedfa6993
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48105
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: mmc: dw_mmc: rename EBIT to EBE

Make naming of "End Bit Error" bit flag consistent with documentation.

BUG=chrome-os-partner:18666
TEST=none

Change-Id: I5b6d297c5b2bca02190ccf9dd3382dc0866e62ee
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48106
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: mmc: dw_mmc: Samsung defines 3 bits per CLKSEL register field

Exynos5250 defines 3 bits each for:
	SDMMC_CLKSEL_CCLK_SAMPLE
	SDMMC_CLKSEL_CCLK_DRIVE
	SDMMC_CLKSEL_CCLK_DIVIDER
fields in CLKSEL register.

See SEC_S5PC520A_EVT1.1_Users\ Guide_Ver.1.10.00.pdf
section "20.6.1.38 CLKSEL"

BUG=chrome-os-partner:18666
TEST=boot on snow/spring. Run hardware_StorageFio test.

Change-Id: I12265929b37d1464eedb76f493bee32298299554
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51040
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: mmc: dw_mmc: check for "supports-hs200" DTS property

"supports-hs200" device tree property indicates the eMMC controller
and board support HS200 (SDR 200MHz) transfer rates. This feature
is eMMC 4.5 only. Older devices will not ask for this transfer rate.
eMMC 4.5 devices on older boards might not work at this transfer rate.

BUG=chrome-os-partner:18666
TEST=Booted on snow and spring. Verified dmesg output that eMMC 4.5 device
   can request and operates at 200 MHz:

	mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req \
	200000000Hz, actual 200000000HZ div = 0) \
	mmc0: new HS200 MMC card at address 0001

Change-Id: I0938998a04652b06665a1f47c883d59f9907b1a4
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48104
Tested-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Grant Grundler <grundler@chromium.org>
CHROMIUM: exynos: initialize mmc0 clock divisors in case FW doesn't

FSYS1 provides the MMC0 clock output. dout_mmc0 and sclk_mmc0 are
currently set to support 50Mhz DDR (100 MHz "slot speed").

BUG=chrome-os-partner:18666,chromium:221828
TEST=booted on snow and spring.  Verified both 50MHZ DDR and HS200 cards
   are detected (with additional patches) and can work as root devices.

Change-Id: Icb95d8dd0ab6cfd2f85e46b58631b2f863a5cf0b
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51041
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: exynos: add "supports-hs200" property to spring dts

Adding "supports-hs200" to DTS enables the dw_mmc driver to run eMMC
clock at 200MHz.
eMMC 4.5 devices support SDR 200MHz bus transfers.
eMMC 4.41 devices support SDR 104MHz and DDR 52MHz (about the same througput).

BUG=chrome-os-partner:18666
TEST=build/booted on spring. Verified kernel dmesg has "Bus speed (slot 0)"
of 200 MHz. Also run StorageFio test to confirm seq read is 80+ MB/s.
     ./run_remote_tests.sh --board=daisy_spring --remote=192.168.1.116 \
     	hardware_StorageFio/control\$

Change-Id: If3e1ad107f645b4f8c79b717a888b1cddb8d1534
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51043
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: mwifiex: rename wapi_rxpn to pn

This array was used for wapi_rxpn only. Now it will be used for
AES_CMAC as well. So make a generic name for it.

Signed-off-by: Ying Luo <luoy@marvell.com>
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:17169
TEST=configure a hostapd-based AP with an RSN PSK and "ieee80211w=2",
and configure a wpa_supplicant client with "ieee80211w=1".

Change-Id: I762db6884b2d8b497ec2e037c9656c492bd53672
Reviewed-on: https://gerrit.chromium.org/gerrit/41039
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: pass key_params pointer in mwifiex_set_encode

'cipher' and 'seq' coming from cfg80211 add_key handler will be
parsed in mwifiex_set_encode() to handle AES_CMAC cipher suite.

Signed-off-by: Ying Luo <luoy@marvell.com>
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:17169
TEST=configure a hostapd-based AP with an RSN PSK and "ieee80211w=2",
and configure a wpa_supplicant client with "ieee80211w=1".

Change-Id: I613264ab14ca9ac76993d29cedcaa31ed78aea68
Reviewed-on: https://gerrit.chromium.org/gerrit/41040
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: add AES_CMAC support in key_material cmd

The sequence counter will be sent to firmware via key_material
command.

Signed-off-by: Ying Luo <luoy@marvell.com>
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:17169
TEST=configure a hostapd-based AP with an RSN PSK and "ieee80211w=2",
and configure a wpa_supplicant client with "ieee80211w=1".

Change-Id: I5fe1d360cc96aef9774c234d3e8ceb0da65a0ed0
Reviewed-on: https://gerrit.chromium.org/gerrit/41041
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
GPU: DVFS: Fix a typo for voltage setting

This patch fixes the correct voltage to 1.2.
This effects a rare set of lot ids so may not have been affecting any
users, but still better to get the fix in.

BUG=chrome-os-partner:19034
TEST=Webgl Many Planets Deep

Change-Id: I62dae8021069952de921157e7e7434102bb1da35
Signed-off-by: Abhinav Kochhar <abhinav.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49039
BACKPORT: PM / Sleep: Print name of wakeup source that aborts suspend

A driver or app may repeatedly request a wakeup source while the system
is attempting to enter suspend, which may indicate a bug or at least
point out a highly active system component that is responsible for
decreased battery life on a mobile device.  Even when the incidence
of suspend abort is not severe, identifying wakeup sources that
frequently abort suspend can be a useful clue for power management
analysis.

In some cases the existing stats can point out the offender where there is
an unexpectedly high activation count that stands out from the others, but
in other cases the wakeup source frequently taken just after the rest of
the system thinks its time to suspend might not stand out in the overall
stats.

It is also often useful to have information about what's been happening
recently, rather than totals of all activity for the system boot.

It's suggested to dump a line about which wakeup source
aborted suspend to aid analysis of these situations.

Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
(cherry picked from commit a938da0682c2487f6aafc9a7c3caa8d675acdb38)

Signed-off-by: Bernie Thompson <bhthompson@chromium.org>

BUG=chrome-os-partner:19817
TEST=Manual, run suspend resume on dut and check for message.

Change-Id: I8a127490ad40613fc665e8b3086e6ee93c4c419a
Reviewed-on: https://gerrit.chromium.org/gerrit/57142
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
CHROMIUM: Fix incorrect usage of IS_ERR instead of checking for NULL.

In mem2mem cases, gsc_prepare_addr may be called with vb coming from
v4l2_m2m_next_src_buf, which may return NULL if no buffers are ready yet.
In no case can gsc_prepare_addr be called with a vb generated by ERR_PTR()
macro.
Also, frame can never be NULL, so remove the check.

This has always been correct in mainline gsc driver.

BUG=chromium:244539
TEST=compile and run video playback

Signed-off-by: Pawel Osciak <posciak@chromium.org>

Change-Id: I6bd0cbbef10ef9077695101ae2929a7f83310bc8
Reviewed-on: https://gerrit.chromium.org/gerrit/56841
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
CHROMIUM: config: use ext4 for ext2/ext3 mounting

The ext4 fs has grown an option to transparently handle mount requests
for ext2 and ext3 filesystems.  This means we can disable both the ext2
and ext3 drivers entirely.  No userspace changes are necessary as the
ext4 driver will register itself as the handler for all three.

This good for a few reasons:
 - upstream treats ext2/ext3 as dead code and all work (both features &
   optimizations) are going into ext4 only
 - Ted has stated that ext4 performs better than ext2/ext3 even when the
   fs itself isn't formatted as ext4
 - Google itself uses ext4 in its infrastructure (it moved away from ext2
   a few years ago) which means it's no longer validating ext2
 - the kernel .text shrinks by ~220k and .data by ~17.5k
 - our rootfs & stateful & encrypted partitions now share code paths, so
   less cache eviction due to both ext2 and ext4 being used (speculation)
 - less code for us to worry about securing :)

Now that we've branched R28, this is probably a good time to make the
switch so as to maximize coverage before the next branch.

BUG=chromium:239821
TEST=booted an alex
TEST=`cbuildbot {arm,amd64,x86}-generic-full` passes (vmtests)
TEST=`cbuildbot {lumpy,x86-alex,daisy}-release` passes (hwtests)
CQ-DEPEND=CL:50835

Change-Id: I4e9c1f0dd94c65c4ceb4b5c34c946dd190d76c7c
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50712
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Thieu Le <thieule@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Paul Taysom <taysom@chromium.org>
CHROMIUM:iommu:exynos deleted dead exynos_sysmmu_tlb_invalidate()

Remove dead functions:
	exynos_sysmmu_tlb_invalidate()
	exynos_sysmmu_set_prefbuf()

BUG=chromium:219207
TEST=code review

Change-Id: I9579a6dcd2ec84be6dabe8b8dce333b1ca8b477b
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57361