msm_fb: display: free previous iommu buffer only at overlay_unset

Since wait4dmap is used at pipe_commit, there is possibility that
iommu buffer had been freed before vsync. Iommu page fault will
happen under this situation. Therefore only previous played iommu
buffer can be freed at overlay_unset. However all iommu buffers
are freed at suspend.

CRs-fixed: 440254
Change-Id: I9c3b77de255b74fd608aa28bb0f2277a58e2ba97
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: Remove the extra freelist in display_commit

There is an extra freelist call to unmap IOMMU source buffers
in display_commit for LCDC interface. This is causing IOMMU
page faults during boot up on targets with LCDC interfaces.
Remove this extra freelist call.

Change-Id: I12a905efc82c5b9751acbc5941a66d0b58027509
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
msm: display: provide mdp bandwidth parameters from board file

Underrun issues can be solved by changing mdp bandwidth parameters:
max_bw, ab_factor and ib_factor. However these parameters are not
universally same for all targets, and one set of values that works for
one target could cause underruns or higher power on other
targets. This is board side change.

CRs-Fixed: 464492
Change-Id: I2a8fbb9018011ddf42dfa50b371e450e38f4351a
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
video: msm: Cleanup after merge

Change-Id: I218a943b3b71b098f7afbf14fa9aca87058d06d6
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
hrtimer: Prevent hrtimer_enqueue_reprogram race

hrtimer_enqueue_reprogram contains a race which could result in
timer.base switch during unlock/lock sequence.

hrtimer_enqueue_reprogram is releasing the lock protecting the timer
base for calling raise_softirq_irqsoff() due to a lock ordering issue
versus rq->lock.

If during that time another CPU calls __hrtimer_start_range_ns() on
the same hrtimer, the timer base might switch, before the current CPU
can lock base->lock again and therefor the unlock_timer_base() call
will unlock the wrong lock.

[ tglx: Added comment and massaged changelog ]

Change-Id: I327d862c28f24b77a62861764393c4bf660a7318
Signed-off-by: Leonid Shatz <leonid.shatz@ravellosystems.com>
Signed-off-by: Izik Eidus <izik.eidus@ravellosystems.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1359981217-389-1-git-send-email-izik.eidus@ravellosystems.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: b22affe0aef429d657bc6505aacb1c569340ddd2
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Taniya Das <tdas@codeaurora.org>
sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
(just when they would have exceeded their ideal_runtime). It makes use
of a a per-cpu hrtimer resource and hence alarming that hrtimer should
be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
rather than being based on number of tasks in a particular cfs_rq (as
implemented currently). As a result, with current code, its possible for
a running task (which is the sole task in its cfs_rq) to be preempted
much after its ideal_runtime has elapsed, resulting in increased latency
for tasks in other cfs_rq on same cpu.

Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
tasks a CPU has across its various cfs_rqs.

Change-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
msm: spm: set vdd directly for current cpu

In cases where a cpu is setting vdd for itself we need not
call msm_spm_smp_set_vdd through smp_call_function_single.

Without this change when CPU calls for itself when interrupts
are disabled we get following warning

[ 38.407752] ------------[ cut here ]------------
[ 38.407752] WARNING: at kernel/kernel/smp.c:320
smp_call_function_single+0xa8/0x1c8()
[ 38.407752] Modules linked in: adsprpc
[ 38.407752] [<c00149b8>] (unwind_backtrace+0x0/0x11c) from [<c0082afc>]
(warn_slowpath_common+0x4c/0x64)
[ 38.407752] [<c0082afc>] (warn_slowpath_common+0x4c/0x64) from
[<c0082b2c>] (warn_slowpath_null+0x18/0x1c)
[ 38.407752] [<c0082b2c>] (warn_slowpath_null+0x18/0x1c) from
[<c00c510c>] (smp_call_function_single+0xa8/0x1c8)
[ 38.407752] [<c00c510c>] (smp_call_function_single+0xa8/0x1c8) from
[<c0058f6c>] (msm_spm_set_vdd+0x48/0x70)
[ 38.407752] [<c0058f6c>] (msm_spm_set_vdd+0x48/0x70) from [<c0056a98>]
(msm_pm_power_collapse+0x13c/0x334)
[ 38.407752] [<c0056a98>] (msm_pm_power_collapse+0x13c/0x334) from
[<c0057120>] (msm_pm_enter+0x170/0x2dc)
[ 38.407752] [<c0057120>] (msm_pm_enter+0x170/0x2dc) from [<c00b7580>]
(suspend_devices_and_enter+0x1d0/0x334)
[ 38.407752] [<c00b7580>] (suspend_devices_and_enter+0x1d0/0x334) from
[<c00b7800>] (pm_suspend+0x11c/0x1f8)
[ 38.407752] [<c00b7800>] (pm_suspend+0x11c/0x1f8) from [<c00b87a4>]
(suspend+0x68/0x180)
[ 38.407752] [<c00b87a4>] (suspend+0x68/0x180) from [<c009b050>]
(process_one_work+0x280/0x488)
[ 38.407752] [<c009b050>] (process_one_work+0x280/0x488) from
[<c009b46c>] (worker_thread+0x214/0x3b4)
[ 38.407752] [<c009b46c>] (worker_thread+0x214/0x3b4) from [<c009f364>]
(kthread+0x84/0x90)
[ 38.407752] [<c009f364>] (kthread+0x84/0x90) from [<c000f108>]
(kernel_thread_exit+0x0/0x8)
[ 38.407752] ---[ end trace da227214a82491ba ]---

Change-Id: I1aa121f57d74860b6bc8620b40699567e55a9d02
CRs-Fixed: 480408
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
rcu: Fix day-one dyntick-idle stall-warning bug

Each grace period is supposed to have at least one callback waiting
for that grace period to complete.  However, if CONFIG_NO_HZ=n, an
extra callback-free grace period is no big problem -- it will chew up
a tiny bit of CPU time, but it will complete normally.  In contrast,
CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to
sleep indefinitely, in turn indefinitely delaying completion of the
callback-free grace period.  Given that nothing is waiting on this grace
period, this is also not a problem.

That is, unless RCU CPU stall warnings are also enabled, as they are
in recent kernels.  In this case, if a CPU wakes up after at least one
minute of inactivity, an RCU CPU stall warning will result.  The reason
that no one noticed until quite recently is that most systems have enough
OS noise that they will never remain absolutely idle for a full minute.
But there are some embedded systems with cut-down userspace configurations
that consistently get into this situation.

All this begs the question of exactly how a callback-free grace period
gets started in the first place.  This can happen due to the fact that
CPUs do not necessarily agree on which grace period is in progress.
If a CPU still believes that the grace period that just completed is
still ongoing, it will believe that it has callbacks that need to wait for
another grace period, never mind the fact that the grace period that they
were waiting for just completed.  This CPU can therefore erroneously
decide to start a new grace period.  Note that this can happen in
TREE_RCU and TREE_PREEMPT_RCU even on a single-CPU system:  Deadlock
considerations mean that the CPU that detected the end of the grace
period is not necessarily officially informed of this fact for some time.

Once this CPU notices that the earlier grace period completed, it will
invoke its callbacks.  It then won't have any callbacks left.  If no
other CPU has any callbacks, we now have a callback-free grace period.

This commit therefore makes CPUs check more carefully before starting a
new grace period.  This new check relies on an array of tail pointers
into each CPU's list of callbacks.  If the CPU is up to date on which
grace periods have completed, it checks to see if any callbacks follow
the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks
follow the RCU_WAIT_TAIL segment.  The reason that this works is that
the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment
as soon as the CPU is officially notified that the old grace period
has ended.

This change is to cpu_needs_another_gp(), which is called in a number
of places.  The only one that really matters is in rcu_start_gp(), where
the root rcu_node structure's ->lock is held, which prevents any
other CPU from starting or completing a grace period, so that the
comparison that determines whether the CPU is missing the completion
of a grace period is stable.

Change-Id: Ic77e2bbe865059aa6f363db284473e9adcf8797e
Reported-by: Becky Bruce <bgillbruce@gmail.com>
Reported-by: Subodh Nijsure <snijsure@grid-net.com>
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Paul Walmsley <paul@pwsan.com>  # OMAP3730, OMAP4430
Cc: stable@vger.kernel.org
Signed-off-by: Jin Hong <jinh@codeaurora.org>
sched: fix rq->lock recursion

Enabling SCHED_HRTICK currently results in rq->lock recursion and a hard
hang at bootup.  Essentially try_to_wakeup() grabs rq->lock and tries
arming a hrtimer via hrtimer_restart(), which deep down tries waking up
ksoftirqd, which leads to a recursive call to try_to_wakeup() and thus
attempt to take rq->lock recursively!!

This is fixed by having scheduler queue hrtimer via
__hrtimer_start_range_ns() which avoids waking up ksoftirqd.

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Change-Id: I11a13be1d9db3a749614ccf3d4f5fb7bf6f18fa1
arm: Remove no-longer-required RCU_NONIDLE wrapper

Commit 21111be8 "ARM: Fix negative idle stats for offline cpu" moved call
to cpu_die() to occur outside of rcu_idle_enter()/rcu_idle_exit() section.
As a result, the RCU_NONIDLE() wrapper to complete() call in
arch/arm/kernel/process.c:cpu_die() is no longer required (and is
technically incorrect to have). Removing RCU_NONIDLE() wrapper also removes
this warning seen during CPU offline:

[Note: Below message has been edited to fit 75-char per line limit.
Insignificant portions of warning message has been removed in each line.]

------------[ cut here ]------------
WARNING: at kernel/rcutree.c:456 rcu_idle_exit_common+0x4c/0xe0()
Modules linked in:
(unwind_backtrace+0x0/0x120) from (warn_slowpath_common+0x4c/0x64)
(warn_slowpath_common+0x4c/0x64) from (warn_slowpath_null+0x18/0x1c)
(warn_slowpath_null+0x18/0x1c) from (rcu_idle_exit_common+0x4c/0xe0)
(rcu_idle_exit_common+0x4c/0xe0) from (rcu_idle_exit+0xa8/0xc0)
(rcu_idle_exit+0xa8/0xc0) from (cpu_die+0x24/0x5c)
(cpu_die+0x24/0x5c) from (cpu_idle+0xdc/0xf0)
(cpu_idle+0xdc/0xf0) from (0x8160)
---[ end trace 61bf21937a496a37 ]---

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Change-Id: I721e6b20651674e6f6f584cf8d814af00b688c91
msm: SSR: Remove useless warning

This is a warning so that developers know to add more restart
order lists to SSR when a new chip is added. This is mostly
irrelevant now because we assume either entire SoC restart on SSR
or independent restart on SSR, not group restarts. Remove this
warning as it is mostly a reminder that nobody is listening for.

Change-Id: Icbf955cb18395d8d5d086b2167c5c329588b9256
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
cm: Update defconfigs

 * Enable recommended power options

Change-Id: I8e3c266e29cb84cf45972d8c8503fe38d2e8e8d7
msm: pm: Add support to query cpu status

During hotplug operation primary core is required to query
cpu registers to determine whether secondary core has
successfully shutdown.

Change-Id: I81bd47ba851698e86269652afe381b0571ca912a
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
jf: Add sleep status device

Change-Id: Ie3a28f36bcdaf0b89d20776e9fba3cbd11813a7d