mach-msm: Some Tweak
Makefile: Enable Ultimate CPU OC up to 2GHz
Release: Neo-008
Revert "lib: Update RWSEM to Linux 3.10"

This reverts commit 80345ed554d969d378e862bbbd7abdc152f6f2a4.
Revert "msm: kgsl: implement server-side waits"

This reverts commit 55bf2b11cd7ae4f8dc277c6564268f838e34fe7d.
Revert "msm: kgsl: use kgsl_mmu_device_setstate() if the GPU is already idle"

This reverts commit e271b1ae537a339ead13cf76682d9761fb570029.
msm: msm_bus: Fix the 64-bit division during interleaving

When interleaving flag is enabled, the bandwidth is divided
between ports. There was an error in the division as the
macro was not correctly updated with the right order of using
bandwidth and port number when 64-bit division function
was used by the bus driver.
Correcting this for fixing the token allocation issues
observed.

CRs-Fixed: 472791
Change-Id: Ie7c7f9557006cbb946eaa9eff4b50771cc60525e
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: msm_bus: Change MDP port interleaved setting

When display driver requests bandwidth on MDP port 0, it was
automatically divided between port 0 and port 1 by the bus driver
as a part of interleaving. Since MDP port 1 was never used,
this did not have any impact.

Now, the display driver needs to use MDP port 1 such that MDP
ports should be able to use the bandwidth non-uniformally.
To enable these ports to use unequal amount of bandwidth,
it is required that bus driver does not divide bandwidth
between port 0 and port 1.
The display team is now responsible for requesting bandwidth
explicitly on both ports.

CRs-Fixed: 474499
Change-Id: I826a4c20a113a32f6d6bcf13f1c6474040f35f46
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
(cherry-pick from Change-Id: I826a4c20a113a32f6d6bcf13f1c6474040f35f46)

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: msm_bus: Add NULL pointer checks.

Bus driver is crashing due to a NULL pointer
access sent by the client. A few NULL pointer
checks have been added to protect the driver
from invalid/NULL client handle.

CRs-Fixed: 458264
Change-Id: I822ad312ba1a0c0939d97eb92ea53094d408a836
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: msm_bus: Explicitly clear client requests before removal

Clients can potentially leave non-zero requests before
unregistering. Such requests persist and cause instability
and severe power and performance impact.

Protect the system against such clients by explicitly
clearing the client requests before unregistration

Change-Id: I6a905b097de41af168b5f5048b682ba995b581c2
CRs-Fixed: 407057
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: msm_bus: Correct the return value from register-client

On failure, return 0, and not a non-zero value as that can
be interpreted as a valid client ID.

CRs-Fixed: 486328
Change-Id: I7a5b448bc398b4a4792170147a5e5317d25f8b3c
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
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>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
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>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
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>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: fix reference to wrong cfs_rq

Commit 7db16c8c (sched: Fix SCHED_HRTICK bug leading to late preemption
of tasks) introduced a bug in sched_slice() calculation by using wrong
cfs_rq for tasks. rq->cfs was incorrectly used as task's cfs_rq, rather
than the correct one to which they belonged.

Fix the bug by using correct cfs_rq for tasks.

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: re-calculate a cpu's next_balance point upon sched domain changes

Commit 55ddeb0f (sched: Reset rq->next_interval before going idle) reset
a cpu's rq->next_balance when pulled_task = 0, which will be true when
the cpu failed to pull any task, causing it go idle. However that patch
relied on next_balance being calculated as a result of traversing cpu's
sched domain hierarchy.

A cpu that is the only online cpu will however not be attached to any
sched domain hierarchy. When such a cpu calls into idle_balance(), we
will end up initializing next_balance to be 1sec away! Such a CPU will
defer load balance check for another 1sec, even though we may bring up
more cpus in the meantime requiring it to check for load imbalance more
frequently. This could then lead to increased scheduling latency for
some tasks.

This patch results in a cpu's next_balance being re-calculated when its
attaching to a new sched domain hierarchy.  This should let cpus call
load balance checks at the right time we expect them to!

Change-Id: I855cff8da5ca28d278596c3bb0163b839d4704bc
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Make sure to not re-read variables after validation

We could re-read rq->rt_avg after we validated it was smaller than
total, invalidating the check and resulting in an unintended negative.

Change-Id: I8543974aad539107768e9e513ca3a8c4cb79b2ff
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Rientjes <rientjes@google.com>
Link: http://lkml.kernel.org/r/1337688268.9698.29.camel@twins
Signed-off-by: Ingo Molnar <mingo@kernel.org>
CRs-Fixed: 497236
Git-commit: b654f7de41b0e3903ee2b51d3b8db77fe52ce728
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s

try_to_wake_up_local() should only be invoked to wake up another
task in the same runqueue and BUG_ON()s are used to enforce the
rule. Missing try_to_wake_up_local() can stall workqueue
execution but such stalls are likely to be finite either by
another work item being queued or the one blocked getting
unblocked.  There's no reason to trigger BUG while holding rq
lock crashing the whole system.

Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.

Change-Id: I75fdaaf4dcaefcf3893e0404d98c8aa91f89934d
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Git-commit: 383efcd00053ec40023010ce5034bd702e7ab373
CRs-Fixed: 519942
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: change WARN_ON_ONCE to WARN_ON in try_to_wake_up_local()

The WARN_ON_ONCE() calls at the beginning of try_to_wake_up_local()
were recently converted from BUG_ON() calls. If these hit it indicates
something is wrong and that may contribute to other system instability.
To eliminate the risk of an instance of one of these errors going
un-noticed because there was an earlier instance that occured long ago,
change to WARN_ON(). If there ever is a flood of these there are bigger
problems.

Change-Id: I392832e2b6ec24b3569b001b1af9ecd4ed6828e7
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: move printk out of spin lock low_water_lock

cpu3 stuck in printk more time in spin lock low_water_lock cause cpu0
get spin lock fail and system crashed.

CRs-Fixed: 521570
Change-Id: I75356a4b4171ae2888ce6cce792f569b5ca8cdcf
Signed-off-by: Tingting Yang <tingting@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>