Tweaked voltages & removed more frequencies (Credit Hellsgod)

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c
Tweaked all the values and voltages
Lowered VDD
wakelock: (tungstwenty's implementation) expanded deleted wakelocks to let us see which wakelock they were before they got deleted.
wakelock: main_wake_lock fix by tungstwenty
freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes

Calling freeze_processes sets a global flag that will cause any
process that calls try_to_freeze to enter the refrigerator.  It
skips sending a signal to the current task, but if the current
task ever hits try_to_freeze, all threads will be frozen and the
system will deadlock.

Set a new flag, PF_SUSPEND_TASK, on the task that calls
freeze_processes.  The flag notifies the freezer that the thread
is involved in suspend and should not be frozen.  Also add a
WARN_ON in thaw_processes if the caller does not have the
PF_SUSPEND_TASK flag set to catch if a different task calls
thaw_processes than the one that called freeze_processes, leaving
a task with PF_SUSPEND_TASK permanently set on it.

Threads that spawn off a task with PF_SUSPEND_TASK set (which
swsusp does) will also have PF_SUSPEND_TASK set, preventing them
from freezing while they are helping with suspend, but they need
to be dead by the time suspend is triggered, otherwise they may
run when userspace is expected to be frozen.  Add a WARN_ON in
thaw_processes if more than one thread has the PF_SUSPEND_TASK
flag set.

Reported-and-tested-by: Michael Leun <lkml20130126@newton.leun.net>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
softirq: reduce latencies

In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.

This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.

This patch changes the fallback to ksoftirqd condition to :

- A time limit of 2 ms.
- need_resched() being set on current task

When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.

Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.

I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :

In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.

Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)

Before patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92

After patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
freezer: shorten freezer sleep time using exponential backoff

All tasks can easily be frozen in under 10 ms, switch to using
an initial 1 ms sleep followed by exponential backoff until
8 ms.  Also convert the printed time to ms instead of centiseconds.

Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Conflicts:
	kernel/power/process.c
freezer: Fix merge error

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Conflicts:
	kernel/power/process.c
fair.c: tweaking the scheduling
makefile: enable -pipe, disable WAIT_SCAN, remove asustek (thx anarkia1976)

Conflicts:
	arch/arm/mach-msm/Makefile
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>
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>
msm_fb: display: fix the hang issue caused by solidfill pipe

When mdp pipe solidfill mode is disabled, the staled pipe info is used
to update mdp pipe regs. This caused mdp hang. Since
mdp4_overlay_rgb_setup function already resets solidfill mode, this
patch removes any pipe register updates that are related to disabling
solidfill mode.

CRs-fixed: 467555
Change-Id: I23f4b29731c9097ab0cc38baa00cd35bc536d2ba
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
audit: kiss goodbye you stupid piece of crap logging messages.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>