video: msm: Remove old post processing overlay integration

Remove old implementation of HSIC and QSEED smoothing/sharpening overlay
integration. Need to replace with new implementation that better integrates
the existing functions of the two APIs.

CRs-Fixed: 380750
Change-Id: Id3469fad16764ed88e74a8da75bb873f726ba366
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
Signed-off-by: Pravin Tamkhane <pravint@codeaurora.org>
video: msm: Add CSC and QSEED support to Overlay API

Add support for CSC and QSEED configuration through MSMFB_OVERLAY_SET and
MSMFB_OVERLAY_PLAY ioctls. Provide better integration than previous attempt
with the existing Overlay and PostProcessing APIs.

CRs-Fixed: 380750
Change-Id: If895391074ef1e7d7a6824d289e1ed9da6a52180
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
video: msm: PCC/GC config register protection

PCC/GC configuration registers are shared with other features. This patch
makes sure that the other features implementations don't overwrite the
existing settings for PCC/GC.

CRs-Fixed: 345395
Change-Id: I5467a4c50eae214181d67a7976eee92c0ae26fe5
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
Revert "msm: display: fb blend setting via MSMFB_METADATA_SET ioctl"

This reverts commit 0667e085db8e2c91996aad1598627d142d2e49cb.

Change-Id: I81e49c1ca4b6f94b23c85deab4a84b89e5d13de0
video: msm: Allow PCC/GC to be disabled/select bins

Current implementation would not set enable/disable bits to PCC/GC nor be
able to select the zero'th bin after selecting the first.

Change-Id: I0f52beb8914cdaecbabe913455c00fb9ea6100db
Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
d2: Initialize low latency PCM devices

 * Disabled on D2 for now though.

Change-Id: I7f0d5d74cc0f103e801c1ed56e40c75f85084b6b
Revert "updating ION headers to support JB_chocolate kernel and mr 1 HAL"

This reverts commit eaab14d0af6511c5c5b5fa8ba6fc06ecc7d041f9.
Revert "Revert "msm: audio: qdsp6v2: Update ACDB driver to use ION""

This reverts commit 73e3a4e95529ada59bf2be7d08645d139a458dd6.
msm: kgsl: Hold the pm_qos vote at all times when ACTIVE

The GPU needs access to the L2 cache while running.  If the
CPU is not also active using the cache can lead to stability
issues.  Keep the CPU out of idle power collapse at all times
while the GPU is running.

CRs-Fixed: 397489
Change-Id: Iab2d8c601e903aadc4060f7c6d67bc128840edbf
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
msm: kgsl: Hold pm_qos vote for active rendering

Differentiate between the screen off case where kgsl shouldn't
hold a pm_qos vote and the screen on case where power rails
may be turned off after a long idle.  restore_slumber now
corresponds to the screen on/off while strtstp_sleepwake covers
the power rail collapse.

CRs-Fixed: 386956
Change-Id: Id4318f1aa87d6ad0653fe5db18c5d33bda1cc8bb
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
ARM: 7133/1: SMP: fix per cpu timer setup before the cpu is marked online

The problem is related to the early enabling of interrupts and the
per cpu timer setup before the cpu is marked online. This doesn't
need to be done in order to call calibrate_delay().

calibrate_delay() monitors jiffies, which are updated from the CPU
which is waiting for the new CPU to set the online bit.

So simply calibrate_delay() can be called on the new CPU just from
the interrupt disabled region and move the local timer setup after
stored the cpu data and before enabling interrupts.

This solves both the cpu_online vs. cpu_active problem and the
affinity setting of the per cpu timers.

Change-Id: Iadb01889e859eedca426af7dbff2a015bc145e82
Signed-off-by: Thomas Gleinxer <tglx@linutronix.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
sched: Cleanup cpu_active madness

Stepan found:

CPU0		CPUn

_cpu_up()
  __cpu_up()

		boostrap()
		  notify_cpu_starting()
		  set_cpu_online()
		  while (!cpu_active())
		    cpu_relax()

<PREEMPT-out>

smp_call_function(.wait=1)
  /* we find cpu_online() is true */
  arch_send_call_function_ipi_mask()

  /* wait-forever-more */

<PREEMPT-in>
		  local_irq_enable()

  cpu_notify(CPU_ONLINE)
    sched_cpu_active()
      set_cpu_active()

Now the purpose of cpu_active is mostly with bringing down a cpu, where
we mark it !active to avoid the load-balancer from moving tasks to it
while we tear down the cpu. This is required because we only update the
sched_domain tree after we brought the cpu-down. And this is needed so
that some tasks can still run while we bring it down, we just don't want
new tasks to appear.

On cpu-up however the sched_domain tree doesn't yet include the new cpu,
so its invisible to the load-balancer, regardless of the active state.
So instead of setting the active state after we boot the new cpu (and
consequently having to wait for it before enabling interrupts) set the
cpu active before we set it online and avoid the whole mess.

Change-Id: Id564d0a195de2b700db29c264ed2f926c4f0ca09
Reported-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1323965362.18942.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>
sched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Conflicts:

	kernel/sched/core.c

Change-Id: Ib22f61c28494bcccc40f9f7fa3812c72e5528203
msm_fb: display: Configure blend after DMA for DSI video

Change-Id: I932c787b26f9f87c56adb35dcbe706cb7b0286d0
msm_fb: display: Enable scaling bit while setting x-flip bit

To enable left-right flip x-scaling bit should be set for
MDP 4.2 and above versions. This fixes the issue when RGB layer
pipes are not properly rotated.

Change-Id: I0afae4aecde39ce3ac4dcbefc0bda93510e7d18a
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
msm_fb: display: fix iommu leak during base layer swap

Retain RGB1 iommu information during  base layer swap
so that iommu used by RGB1 can be freed back to pool later.

Change-Id: Ibed85179284743dc8a9d1434f0c81626b0567e16
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: Timeout pan display if time greater than 100ms

Timeout if pan display is taking more than 100ms to complete. This
will unblock the userspace thread and continue. This will solve
the hang issues.

Change-Id: Ica6a395b0e992263567633d6dc93a92ee1fa59cf
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
(cherry picked from commit 7c270369ccb7eca4934d6005b1960ac7ec2ed2fc)
msm_fb: display: extend mutex protection for mdp pan display

When mdp commits a buffer to play, functions inside pan display, e.g.
mdp4_overlay_mdp_perf_upd are based on the current state of play, so
extending mutex to the scope of pan display to avoid race conditions.

Change-Id: I2e55567fd21de3738be066a2dee298d8122f12a3
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: Add SMP-safety for PPP Operations

Adds protection using spinlock for the variable used in
controlling the PPP operations

Change-Id: Iba6ef5e32d38668bd110ed23ee9631aa40de79e0
Signed-off-by: Pradeep Jilagam <pjilagam@codeaurora.org>
msm_fb : display : Block RGB downscale in MDP 4.0 and 4.1

Downscale is not allowed on RGB pipes in MDP 4.0 and 4.1. Hence,
fail the OVERLAY_SET ioctl for such configurations.

Signed-off-by: Pradeep Jilagam <pjilagam@codeaurora.org>
(cherry picked from commit 3545573720822ce97ec37586f10fdf74a6d4f090)

Change-Id: I8445c18ac21cb7322eb9eb4c802623df5da07eb7
Signed-off-by: Gopal Goberu <ggober@codeaurora.org>