msm: vidc: Free smem client after moving core to UNINIT

If userspace crashes prematurely, there will be a good chance that the
driver hasn't unmapped or freed certain buffers.  These buffers will be
freed in the state transition to UNINIT.  At that point the smem client
needs to be valid for the free/unmaps to be valid.

CRs-Fixed: 611946
Change-Id: I089dcbd1e79f1c2a8671e5719d3a5dbc9926b252
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
msm: vidc: initialize venus hfi locks during hfi creation

Venus hfi locks were initialized during core init,
which is invoked when the first video instance is
created. If a debugfs command is executed before
starting the first video instance, then video driver
crashes trying to lock an uninitialized mutex.

Change-Id: I472e9de91dada94a2728dd02c747e7fde63e3e4f
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm: vidc: Re-program the vbif settings post-power collapse

As part of power collapse we turn off the venus GDSC. When we turn it
back on, we need to re-program the VBIF registers to overwrite the
reset values.

CRs-Fixed: 585609
Change-Id: Ic2ac40274773f9592f510ccb573b9d4920a8647f
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
msm: vidc: Add min resolution check for video session

Add a check for minimum supported video resolution, based
on firmware capabilities and reject unsupported video sessions.

Change-Id: Ib5a4eb6e6ab66408cf13829e20d3933138f357c1
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm: vidc: Add description of LTR Extradata

The missing string descriptor caused a mismatch in array sizes
causing the v4l2 control framework make an out of bounds access.

Change-Id: I9a9f64e16ca95163d800702d94528833f5892537
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
msm: vidc: Query the core on VIDIOC_G_FMT

Previously we only queried the core for buffer requirements in
VIDIOC_REQBUFS, and relied on that information in _G_FMT.  However,
there's no expectation that the client calls _REQBUFS before _G_FMT,
which leads to stale information being returned as part of _G_FMT.

As such, always retreive fresh info from the core for either ioctl.

Change-Id: Ife94343f4bd4f62da7f2bef4266076ceed409bca
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
msm: vidc: detect mbaff information from firmware

Firmware will set the FBD flags if mbaff interface
is detected for decoded video bitstream. Previously
the mbaff information was parsed in the v4l2 video
client, but now firmware parses and sends the information.

Change-Id: Ic557cdb7bf49aab3eb29a3f3aa3e363bf7223a36
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
linaro fixes
	modified:   arch/arm/boot/compressed/Makefile
	modified:   net/bluetooth/hci_conn.c
sched: disable gentle fair sleepers
initial s2w dt2w code import from @showp1984

Signed-off-by: Paul Reioux <reioux@gmail.com>
mdss:mdss_dsi_panel.c: add s2wake/dt2wake screen on/off hooks

Signed-off-by: Paul Reioux <reioux@gmail.com>
sweep2wake/doubletap2wake: adapt for falcon_umts (aka Moto G)

Signed-off-by: Paul Reioux <reioux@gmail.com>
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: anerik <anerikgames@gmail.com>

Conflicts:
	block/Kconfig.iosched
	block/Makefile
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Add SIO I/O scheduler

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: anerik <anerikgames@gmail.com>

Conflicts:
	block/Kconfig.iosched