msm_fb: display: prepare clocks before enable AHB clock

Clocks need to be prepared before enabled and unprepared after
clock disabled.

CRs-fixed: 466843
Change-Id: I5180c98a2c5fd4bd867272ee1d2bf274ff15d215
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: add one more pipe_commit delay before free ion buffer

It is possible that two consective pipe_commits happen within
same vsync period.  This will cause iommu page fault due to an ion buffer
that is being fetched by mdp's pipe is freed. It needs one pipe_commit
delay to free ion buffer to prevent iommu page from happening. Therefore
an extra free stage is needed to empty ion buffer free list.
Also, ION_IOMMU_UNMAP_DELAYED flag is not necessary at mapping of an
ion buffer since one pipe_commit delay had been added.

Change-Id: I340e002e8dc30b6faa0c095ba042eab50e8b7c88
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: add mdp master port1 bandwidth request

mdp bus traffic go through both mdp port0 and port1, but now mdp
bandwidth request is only for port0.

Change-Id: Ie902de6362cd9225abf6e9c42f260b5af7c3c6f8
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: balance bus bandwidth on mdp axi port0 and port1

mdp read and write clients are connected on both mdp port0 and port1,
however, the bus bandwidth request is made on only port0. This change
divides mdp bw requests to port0 and port1 based on pipe connections
to mdp ports.
ab - no scaling factor - port0 and port1 split
ib - scaling factor - port 0 and port1 split

Change-Id: I9050d1178f634ca908675fa826d08bee09e2a2f3
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: add scaling factor for mdp ab

system profiling found that mdp downscaling needs larger bandwidth
that is related to mdp ab request, so adding scaling factor to mdp ab
calculation reduces the chance of underruns.

ab - scaling factors - port0 and port1 split
ib - 1.5 x ab - no split and same on both ports

Change-Id: I4fde87fce1cd292e317a8261e4700cf98662d09d
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: issue completion when disabling vsync irq

When vsync irq is disabled, vsync_wait_cnt is reset to zero and
completion is issued out as they are done in isr to make sure all
wait_for_completion is released.

Change-Id: I689f0c8cde43404d0caf5bb4644efa6385798d0e
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
mms_fb: display: init pipe default configure as solidfill

Initialize mdp pipes default config as solid fill so that
there will have no memory fetch if pipe are staged into
mixer while flush bits are left behind and set at next vsync.
This is will prevent mdp iommu page fault from happening
at address 0x00000000 during resume.

Change-Id: Ide944ec1d069629f1ae2ecd0daf49c69ce2af2eb
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: Do a pre-fill to writeback buffers.

When switching mdp operating mode to blt, writeback buffers need
pre-fill. Move the pre-fill code from isr routine to do_blt, where
actual switch to blt mode happens.

CRs-fixed: 471098
Change-Id: I0f845397894c749ac518a1fa605f84cd5fc2ad15
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
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_fb: display: fix iommu page fault when iommu buffer freed

There has possibility that pipe commit come very close to next vsync.
This may cause two consecutive pipe_commits happen within same vsync
period which cause iommu page fault when previous iommu buffer is
freed since mdp stil fetching it. Set ION_IOMMU_UNMAP_DELAYED flag
at ion_map_iommu() to add delay un mapping iommu buffer to fix this problem.
Otherwise four buffer mechanism is needed to avoid this problem..
Also ion_unmap_iommu() may take long time to free an ion buffer. Move
mdp4_overlay_iommu_unmap_freelist(mixer) called after stage_commit()
to increase chance to have pipe_commit (up to stage_commit) is completed
within same vsync period
This patch also fix an potential race condition at wait_for_completion
between show_event thread and wait4vsync thread.

Change-Id: I673b0e368bbcd3120bc26569fe7a7bb82931daaa
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
(cherry picked from commit ada63be0fd32e729e4b91aeeea2a5cfe0830148c)
(cherry picked from commit 799796f15e0b78ffe47975db1cf7f3791cb98129)
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: Fix negative idle stats for offline cpu

We see negative idle stats because of cpu dying without
cleaning up idle entry statistics. When a cpu is offline,
the most immediate thing you'd want to do is just call
into cpu_die() and not waste time calling notifier(IDLE_START).

CRs-Fixed: 414554
Change-Id: Iadc6a3ca39997e0ccf65d2a29b004e24b1b211a1
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>