CHROMIUM: s5p-mfc: fix encoder bitrate deviation

when Rate Control is enabled, mfc tends to
deviate far away from user requested bitrate.

default GOP size should be 12 for mfc encoding.
This is as per v4l2 controls documentation
Documentation/DocBook/media/v4l/controls.xml

BUG=chrome-os-partner:18019
TEST=local build, run on CrOS pit
test encoder for various bitrates and check if we get so.

Change-Id: I9f60df1d0d3f53f47f610614f4619a444b681ff1
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66805
Tested-by: kiran <kiran@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66925
Commit-Queue: kiran <kiran@chromium.org>
v4l2: clear m2m context from job_queue before ctx streamoff

When streamoff is called on the context and the context
is added to the job_queue,
1] sometimes device_run receives the empty vb2 buffers (as
   v4l2_m2m_streamoff is dropping the ready queue).
2] sometimes v4l2_m2m_job_finish may not succeed as the m2m_dev->curr_ctx
   is made NULL in the v4l2_m2m_streamoff()

The above points may stop the execution of the other queued contexts.
This patch makes sure that before streamoff is executed on any context,
that context should "not be running" or "not queued" in the job_queue.
1] If the current context is running, then abort job will be called.
2] If the current context is queued, then the context will be removed from
   the job_queue.

BUG=chrome-os-partner:21555
BUG=chrome-os-partner:22239
TEST=Run 3 instances of 1080p mp4 video.
Refresh videos multiple times. No hang observed.

Change-Id: I92cf6bb45478665b500641f0879a014cccdc05cc
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64192
Tested-by: Arun Mankuzhi <arun@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/67022
Commit-Queue: <kiran@chromium.org>
Tested-by: <kiran@chromium.org>
CHROMIUM: s5p-mfc: set B-frames as 2 while encoding

set default number of B-frames as 2 while encoding
for better compression. This User can however change
this setting using V4L2_CID_MPEG_VIDEO_B_FRAMES.

BUG=chrome-os-partner:22249
TEST=run encoder on snow/peach.

Change-Id: If62350370e59811afbe3e11ab95c95865843b60b
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/67044
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: kiran <kiran@chromium.org>
Tested-by: kiran <kiran@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167202
Commit-Queue: <kiran@chromium.org>
Tested-by: <kiran@chromium.org>
CHROMIUM: gsc-m2m: report correct format bytesperline and sizeimage

Explicitly specify sampling period for subsampled chroma formats, so
stride and image size are properly reported through VIDIOC_{S,G}_FMT.

Signed-off-by: John Sheu <sheu@google.com>

BUG=chromium:221441
TEST=local build, run on CrOS snow

Change-Id: I01a4485045c7f0dda44f76bfc31566b76170f912
Reviewed-on: https://chromium-review.googlesource.com/66692
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
exynos-gsc: handle timeout during gsc release

<NO UPSTREAM MERGE REQUIRED>

When stop streaming / abort is called on gsc context
and if it times out, clear vb2 queues and call v4l2
job finish to exit properly

BUG=chrome-os-partner:22239
TEST=run vdau on snow

Change-Id: I7209d5a0a24ebf9332c056c3960734b0fab9854d
Signed-off-by: avnd kiran <avnd.kiran@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/167605
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
CHROMIUM: gsc: fix a possible race during ctx change

changing gsc context state during stop_streaming/abort
without an appropriate lock could cause a possible race
with other state modifications happening in irq context

BUG=chrome-os-partner:22239
TEST=run vdau on snow

Change-Id: Ia594094327abaa39cf93fa1a23cc2b38d0a05a4d
Signed-off-by: avnd kiran <avnd.kiran@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/167606
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
CHROMIUM: gsc: Handle ctx job finish when aborted

during abort, there could be unfinished jobs in gsc queue.
this makes application hang indefinitely. Handle this job
finish during abort.

BUG=chrome-os-partner:22239
TEST=run gsc stress test for multiple ctx

Change-Id: I79025992fcf6b982b52ff32c2a483800ffd6e3f0
Signed-off-by: avnd kiran <avnd.kiran@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/167607
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
CHROMIUM: atmel_mxt_ts - add lid event listener

The patch tries to add a LID input event filter to listen for SW_LID events
to enable/disable touchpad when LID is open/closed.

BUG=chrome-os-partner:20494
TEST=on device, open a terminal in a tab and type the following command
	tail -F /var/log/messages | grep atmel
  and follow steps:
  1. hook up an external monitor, close the lid and check if
     all atmel touch device(s) are disabled from the output of
     the command above.
  2. then open the lid and check if all atmel devices are enabled
     and touch devices are working normally.
  3. remove the external monitor plug, close the lid and open it.
  4. check if touch devices are disabled and then enabled, and all
     touch devices are still working.

Change-Id: I4afc66705dfdb67fc8a69d645f250fc4a0a940cf
Signed-off-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167828
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Chung-yih Wang <cywang@google.com>
CHROMIUM: input: cyapa: don't update firmware when watchdog reset bit is on

when watchdog reset bit is set,
writing flash block data will immediately fail.
so don't do firmware update when watchdog reset bit is set,
and when write flash block is on executing,
ignore the watchdog reset bit and reserved bits.

BUG=chrome-os-partner:18410
TEST=test on daisy platform
Without this patch, firmware image will be erased
and new firmware update will fail when watchdog reset bit is set.

Change-Id: I1fbe6f84cf6100f82681497e090077e6b93f96f0
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: https://chromium-review.googlesource.com/64756
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
BACKPORT: mm: remove compressed copy from zram in-memory

Swap subsystem does lazy swap slot free with expecting the page would be
swapped out again so we can avoid unnecessary write.

But the problem in in-memory swap(ex, zram) is that it consumes memory
space until vm_swap_full(ie, used half of all of swap device) condition
meet.  It could be bad if we use multiple swap device, small in-memory
swap and big storage swap or in-memory swap alone.

This patch makes swap subsystem free swap slot as soon as swap-read is
completed and make the swapcache page dirty so the page should be
written out the swap device to reclaim it.  It means we never lose it.

I tested this patch with kernel compile workload.

1. before

   compile time : 9882.42
   zram max wasted space by fragmentation: 13471881 byte
   memory space consumed by zram: 174227456 byte
   the number of slot free notify: 206684

2. after

   compile time : 9653.90
   zram max wasted space by fragmentation: 11805932 byte
   memory space consumed by zram: 154001408 byte
   the number of slot free notify: 426972

[akpm@linux-foundation.org: tweak comment text]
[artem.savkov@gmail.com: fix BUG due to non-swapcache pages in end_swap_bio_read()]
[akpm@linux-foundation.org: invert unlikely() test, augment comment, 80-col cleanup]
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Shaohua Li <shli@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit b430e9d1c6d416306d44dbf3aa3148be7af78abc)
Signed-off-by: Stephen Barber <smbarber@chromium.org>

Conflicts:
	mm/page_io.c

BUG=chromium:282724
TEST=boot new kernel and run platform_CompressedSwapPerf, verify that
performance improves

Change-Id: I2a307470bc50bf4cc8564fa60b158b9361fa0796
Reviewed-on: https://chromium-review.googlesource.com/168500
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
UPSTREAM: crypto: fix larval_kill race

This makes sure racing larval lookups don't end up with a handle on the
same larval, causing a refcounting bug leading to a double list-removal
and double-free. If duplication is detected, wait for the existing larval.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

BUG=chromium:244581
TEST=link build, PoC fails, normal eCryptfs okay

Change-Id: I3f8d1e27f1bc3db71500ee7360a324f26892cae7
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168580
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
UPSTREAM: HID: validate HID report id size

The "Report ID" field of a HID report is used to build indexes of
reports. The kernel's index of these is limited to 256 entries, so any
malicious device that sets a Report ID greater than 255 will trigger
memory corruption on the host:

[ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
[ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b

CVE-2013-2888

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org

BUG=chromium:280729
TEST=link build, exploit fails

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167512
Reviewed-by: Aaron Durbin <adurbin@chromium.org>

Change-Id: Ib17fcb2e83a613aee04d8a2e5ca9ccfe65739d98
(cherry-picked from kernel-next ToT aa4b1d59f3564fc2d15dc4a004d88cd0ac01b844)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168775
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
drm/exynos/mixer: When powering on, wait for win commit to complete

If a window was enabled at DPMS Off (mixer_poweroff), it will
automatically be re-committed at DPMS On (mixer_poweron) via mixer_apply.

At the mixer VSYNC interrupt after which all such windows (layers) have
been updated, the mixer_irq_handler will call
exynos_drm_crtc_finish_pageflip().

If no actual page flips had been requested, this is fine, since the crtc
layer will just return immediately.

However, this introduces a race.

The mixer driver has a weakly enforced "one flip per layer per
layer-update" policy.
Once a layer (window) has been updated, we do not permit another
update to that same layer until all pending layers have been updated.

Instead, mixer_commit() would update the mixers layer registers
(eg, MXR_GRAPHIC_BASE), but not increment the layer update count (by
setting MXR_CFG.LAYER_UPDATE).

This can get triggered if userspace requests a pageflip after
mixer_apply (DPMS ON), but before mixer_irq_handler calls
exynos_drm_crtc_finish_pageflip().  In this case, when
exynos_drm_crtc_finish_pageflip() does get called, the reference counting
will get quite confused - it will think that the mixer just flipped to
the userspace FB, but in fact, it just flipped to the FB that was active
before DPMS Off.  Thus, the currently-scanned out FB will get free'd
causing a mixer- iommu page fault.

To fix this, we can wait for all of mixer_apply's committed layers to
complete before releasing returning from DPMS On, guaranteeing that there
won't be a race with userspace flip requests.

Note: This race described above is particularly acute if the cursor layer
is active at DPMS Off.  In this case, the window from mixer_apply until
MXR_CFG.LAYER_UPDATE_COUNT == 0 can be as much as two vblanks, since the
mixer only decrements the LAYER_COUNT once per vblank.

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

BUG=chromium:288806
TEST=0. ssh to device
     1. Attach External monitor to HDMI
     2. Move pointer to External Monitor
     3. Select a text box to get a blinking cursor
     4. DISPLAY=:0.0 xrandr --output eDP-1 --off
     => try 10+ times... no crashes
     3. login and try with aquarium on HDMI & big-buck-bunny on LCD
     4. DISPLAY=:0.0 xrandr --output eDP-1 --off
     => no crashes
TEST=powerd_dbus_suspend w/ and w/out HDMI attached monitor

Change-Id: Ia0dcebd9ebdab39fd91b30dc93a42be7d8f28e84
Reviewed-on: https://chromium-review.googlesource.com/168748
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: config: turn on highmem on all i386

We used to turn this on with a USE flag but in reality we might as well turn it on everywhere.

BUG=chromium:282474
TEST=make sure kernel_ConfigVerify still passes

Change-Id: Iac264c87f3d2bad15dcc8248734252539106ffcd
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167680
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
ARM: dts: Prepare for "-rev4" and "-rev5" snow by splitting snow dts

The "-rev4" snow board will have slightly different DRAM but is the
same as previous revisions from a kernel perspective.  It can share a
device tree with the older revs.  Note that it has a new U-Boot that
will know to pick a -rev4 device tree, so be nice and put the "-rev4"
compatible string in (though it's not strictly compatible).

The "-rev5" snow board will have a few minor component changes from
the old snow boards and will eventually need tweaks in the device
tree.  Pave the way for this new board changes by adding a "-rev5"
device tree for snow.  The U-Boot on this new board will know to pick
the -rev5 device tree.  At the moment the "-rev5" device tree is
identical to the "-rev4" device tree, but we will soon start adding
differences.

This change will need a future (non-dts) change to start testing for
"google,snow-any".

See (Ib6cbe84b0d038d256b0a18b123886bec1dccf8a0 and
If8568fb26cfba1b75e8a104a2811e3c415401412) for new U-Boot CLs.

BUG=None
TEST=With .90.2 U-Boot, dmesg | head => "Google Snow Rev 0-4"
TEST=With rev4 U-Boot, dmesg | head => "Google Snow Rev 0-4"
TEST=With new U-Boot, dmesg | head => "Google Snow Rev 5+"

Change-Id: Ic18760429396d92c6328dbbadcd66610006bf9d7
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167484
Reviewed-by: Olof Johansson <olofj@chromium.org>
ARM: snow: Change the snow test from "google,snow" to "google,snow-any"

We've got a few places in our code (mostly ugly hacks that we are
eventually trying to get rid of) where we need to specifically test
whether we're on a "google,snow" board.  Unfortunately we can no
longer use this test because:
- We have a new "-rev4" coming out that needs a different dts file.
- That new dts file can't include "google,snow" as a compatible string
  because then the old U-Boot might pick it instead of the rev3 one.

...so we've introduced a "google,snow-any" as a stopgap.  Device tree
files have been updated in Ic18760429396d92c6328dbbadcd66610006bf9d7
so that any revision of snow will match "google,snow-any".

BUG=None
TEST=Use .90.2 U-Boot and see LCD comes up
TETS=Use new U-Boot and see LCD comes up

Change-Id: I4d25277142a3f12f02b20f88eae4b769abf60e4f
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167485
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
CHROMIUM: Input: cyapa - add lid event listener

The patch to add a LID input event filter to listen for SW_LID events
to enable/disable touchpad when LID is open/closed.
This was ported from cywang's patch in the atmel_mxt_ts driver.
See 014f649ea566903b5e72f162fe1a6b7ccd56d6ea

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:220941
TEST=on device, open a terminal in a tab and type the following command
        tail -F /var/log/messages | grep cyapa
  and follow steps:
  1. hook up an external monitor, close the lid and check if
     all atmel touch device(s) are disabled from the output of
     the command above.
  2. then open the lid and check if all cyapa devices are enabled
     and touch devices are working normally.
  3. remove the external monitor plug, close the lid and open it.
  4. check if touch devices are disabled and then enabled, and all
     touch devices are still working.

Change-Id: Ib72cac1847c2fd59ff1e36e04feab39a5f92fb97
Reviewed-on: https://chromium-review.googlesource.com/169215
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
CHROMIUM: s5p-mfc: Remove one frame delay in vp8 decoder

MFC v6 has 1 frame delay between decoded frame and displayed frame
To remove one frame delay for Vp8 decoder in MFC v6, use
decode frame address and decode frame status instead of
display frame address and display frame status from MFC.
This change is not valid for H264 decoder because decoder order
may not be the same as display order. Hence for H264 decoder
use display frame registers only.

BUG=chrome-os-partner:22506
TEST=Ran webm file in browser.
vda unittest, decode latency of 720p vp8 stream is reduced
from 50ms to 14ms and 360p is reduced from 42ms to 6ms

Change-Id: I66513d3096fbbdfd1d4c89a9187a04ff8b1e8da0
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/169083
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
Tested-by: Wu-Cheng Li <wuchengli@chromium.org>
UPSTREAM: ath9k: Fix issue with parsing malformed CFP IE

All QCA chips have the ability to parse the CF Parameter Set
IE in beacons. If the IE is malformed in the beacons from some
APs [1], the HW locks up. In AP mode, a beacon stuck would happen
and in client mode, a disconnection usually is the result.

To fix this issue, set the AR_PCU_MISC_MODE2_CFP_IGNORE to ignore
the CFP IE in beacons - this is applicable for all chips. For
AP mode, if this issue happens, the NAV is also corrupted and has
to be reset - this will be done in a subsequent patch.

[1] : http://msujith.org/ath9k/cfp/Malformed-CF-Param.png

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=chromium:289507
TEST=Automated functional tests

Change-Id: If939c1f9bbf95a01fa3ec5bc27c7f54bf9a1507c
Reviewed-on: https://chromium-review.googlesource.com/168886
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
CHROMIUM: ASoC: samsung - make hdmi_audio ignore non-playback requests.

The hdmi_audio plugin callbacks change the HDMI audio state even if
those requests are not for playback (like recording). This inadvertently
makes stopping recording turn off HDMI audio playback. Now we ignore
those requests.

BUG=chrome-os-partner:22492
TEST=On daisy, while playing a wav file, start and stop recording. The
playback should not be affected.

Change-Id: I879732206b2c1e67730694d65fd77e5062d2af5b
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169515
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>