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>
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)

Conflicts:

	drivers/video/msm/mdp4_overlay_dsi_cmd.c
	drivers/video/msm/mdp4_overlay_dsi_video.c
	drivers/video/msm/mipi_dsi.c
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>
msm_fb: display: add fput_light to frame buffer

Frame buffer's (fb0) ref_count need to be balanced. overlay_play()
increase fb0's ref_count (fget_light). This patch will decrease fb0's
ref_count by calling fput_light after commit

(cherry picked from commit 7d136bef71281855cd224ccc967e4e95286f5356)

Change-Id: I9ba6d5c73cdb29c32a665d2b7b90df996c5b39e6
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: free base layer pipe at adb stop

Base layer pipe need to be freed at adb stop so that same
pipe can be allocated at adb start.

CRs-fixed: 390644
Change-Id: I948bb27687cfe1c96cc3b071b7bb9bb84b2c52c6
Signed-off-by: Kalyan Thota <kalyant@codeaurora.org>
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Revert "msm: display: add mutex for display driver entries"

This reverts commit 87bc4275423d2f4bc4a60aa6b3813f3f20358f17.

Change-Id: I33a2fc456b7ab07f267661ed8f64c03da65ca186

Conflicts:

	drivers/video/msm/msm_fb.c
msm_fb: unlock semaphore on error

Change-Id: Id9bc387d07319619cb100e961c7e84f8f3cc7af3
Signed-off-by: Iliyan Malchev <malchev@google.com>
msm_fb: display: Assign proper destination rectangles to mdp blit

Add check for (90 + Flip Horizontal) and Flip Vertical cases to assign
proper destination rectangle parameters to avoid corrupted frame
buffer content.

CRs-Fixed: 344807
Change-Id: I7e7b0b8d26f08f63a6f9c55eedd37f31cf0348d7
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
ASoC: msm: reduce period_bytes_min for voice call

- Allow smaller buffer size for voice call to
  comply with MR1 audio HAL

Change-Id: Iaffca753ad07889b08ae4b6154e8d596950a979e
Signed-off-by: Mingming Yin <mingming@codeaurora.org>
video: msm: Allow MDP to use max clock rate

Change-Id: Ifafee601093231869f490783a63a3d0f2206e512
printk: Defer CPU_ONLINE console flushing

The flushing of the console in the CPU_ONLINE callback on a hotplug
is rather slow, taking up to 11 ms to complete. Defer this to lower
hotplug latency.

Change-Id: If96089fe2c6cd6024d1a9e2bac35296aea75cf9e
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
msm_fb: dsiplay: fix frame buffer f_count leak

Frame buffer maintains a reference count (f_count) which increased
by fget() and decreased by fput(). overlay play will apply
fget() to frame buffer if it was the soruce buffer and fput()
will be applied to it after pipe commit done. However there has
extra fput() apply to frame buffer at the time pipe is freed.
This patch fix the problem by  clear MDP_MEMORY_ID_TYPE_FB from
pipe's flags to avoid extra fput() applying to frame buffer.

CRs-fixed: 411394
Change-Id: Ib2b72e6277480b5ace23cda554be485d9d477b3d
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: call the backlight control before FB_BLANK_POWERDOWN

You might see the white line while lcd off. You should turn lcd backlight
off before lcd off to avoid that issue. So call the notifier for backlight
before handling of FB_BLANK_POWERDOWN in msm_fb.

Change-Id: I3bd08025a949ec02a1fba7cef98a13d8977c135b

Conflicts:

	drivers/video/msm/msm_fb.c
msm_fb: Clean up the fix for error in y-offset check in FB driver

There is a failure observed in yres_virtual offset check and every
third frame gets skipped without an error message. Due to this high
fps is noticed in the test applications. Correct the yres_virtual
offset check.

Change-Id: Iddce0b75e0a9c466adad6eb5726203ae0586c27b
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>