cpufreq: Retain only online cpus in managed_policy->cpus

cpufreq's handling of cpu online event can incorrectly initialize
managed_policy->cpus to include offline cpus. This causes cpufreq
governors to include offline cpus in their idle time computation, which
causes frequency to shoot up beyond normal levels (on systems where 2 or
more cpus need to be synchronized wrt frequency change).

This frequency shootup was not seen prior to commit 21111be8 which
changed idle time accounting for offline cpus. Prior to commit 21111be8,
idle time statistics for offline cpus would include their offline time
as well. Post commit 21111be8, offline time is not included in a cpu's
idle time statistics.

As a result, ondemand (or other cpufreq) governors would see unchanged
idle time for offline cpus, causing them to interpret those (offline)
cpus as 100% busy, which is wrong.

This patch fixes the issue by modifying cpufreq's hotplug handling to
retain only online cpus in managed_policy->cpus field. cpufreq governors
would then skip such offline cpus from idle time calculations.

Change-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
nanosleep: use freezable blocking call

Date	Wed, 1 May 2013 18:35:06 -0700

Avoid waking up every thread sleeping in a nanosleep call during
suspend and resume by calling a freezable blocking call.  Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.

This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.

Signed-off-by: Colin Cross <ccross@android.com>
af_unix: use freezable blocking calls in read

Date	Wed, 1 May 2013 18:35:08 -0700

Avoid waking up every thread sleeping in read call on an AF_UNIX
socket during suspend and resume by calling a freezable blocking
call.  Previous patches modified the freezer to avoid sending
wakeups to threads that are blocked in freezable blocking calls.

This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.

Signed-off-by: Colin Cross <ccross@android.com>
ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode

The reset value of the BCR, BVR, WCR, and WVR registers are all
UNKNOWN on ARMv7. Unfortunately, reset_ctrl_regs() clears these
registers *after* enabling monitor mode, not before, and so some
implementations may experience UNPREDICTABLE behavior if the
reset values of these registers are non-zero. Clear the
breakpoints before enabling monitor mode so that we don't
experience boot hangs/loops due to breakpoints being enabled
out of reset.

Change-Id: I029fbe40725e803183544ddd6fe40285de4137e8
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: hw_breakpoint: enable HAVE_HW_BREAKPOINT feature flag

HAVE_HW_BREAKPOINT was disabled temporarily from commit
480a82f59712136b51ee5ca05c4f22c1738010c5. Issue not seen with the
latest kernel hence re-enable the feature and fix merge issue from
previous kernel upgrade.

Change-Id: Ia6e7e8282c848dd73108e4d951b3375bb7caa63c
Signed-off-by: Jin Hong <jinh@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
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>
drivers/input/evbug.c: silence annoying dmesg log spam
ARM: proc: Add Krait proc info

Add processor info for the Qualcomm, Inc. Krait family of
processors, to use the generic ARMv7 initialisation
procedure but explicitly enable the IDIV hardware
capability flag.

Change-Id: I080f60189fada2e4f87c79c6b8ef522cdc070759
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
drivers/tty/smux_private.h: SLAB/SLOB compatibility fixup

Signed-off-by: Paul Reioux <reioux@gmail.com>
crypto: msm: Fix Uninitialized flags

Due to uninitialized "flags" field in the request structure,
incorrect choices are made in the qce driver layer with
regards to setting crypto hardware registers.

Initializing the flags fixes this incorrect setting of the
registers.

Change-Id: Ic40319ea5e15e66cbafd28f727a9bcc6ea41b1ca
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Revert "af_unix: use freezable blocking calls in read"

This reverts commit ac41f1d271ccd0f35b2dce3ff64f2fa78efe532a.
ASoC: add missing updates from CAF

CAF patch updated board file for 8064 but LGE split the files and the update
was not applied to mako board

Signed-off-by: faux123 <reioux@gmail.com>
power: pm8921-charger: Don't pollute kmsg when baterry < 10%

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
power: pm8921: Change info message to debug

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
mach-msm: board-mako-display: Use default values for LCD color temperature

Probably bootloader in 4.3 does not pass the correct command line
to the kernel to initialize LCD color temperature values during
fastboot boot command.
It should pass "lge.kcal=0|0|0|x" value.

Use default values to work around the issue.

Thanks @mskip from XDA for reporting this.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
core.c: Disable Software CRC check
timer: optimize apply_slack()

__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but cheaper.
find_last_bit was showing up high on the list when I was profiling for stalls
on icache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
board-mako-sound: Disable DEBUG print for Amp
mmc: core: Fix possbile memory leak

Fix possible memory leak detected by kmemleak:

unreferenced object 0xc0f80f00 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937508 (age 82.980s)
  hex dump (first 32 bytes):
    6d 6d 63 30 5f 64 65 74 65 63 74 00 72 79 2e 68  mmc0_detect.ry.h
    00 07 00 00 68 77 63 61 70 2e 68 00 02 00 00 70  ....hwcap.h....p
  backtrace:
    [<c010a1fc>] __kmalloc+0x164/0x220
    [<c01e1630>] kvasprintf+0x38/0x58
    [<c01e1668>] kasprintf+0x18/0x24
    [<c02fcf60>] mmc_alloc_host+0x114/0x1b4
    [<c0311c84>] msmsdcc_probe+0xc14/0x1fd8
    [<c022b40c>] platform_drv_probe+0x14/0x18
    [<c022a144>] driver_probe_device+0x144/0x334
    [<c022a394>] __driver_attach+0x60/0x84
    [<c022884c>] bus_for_each_dev+0x4c/0x78
    [<c0229720>] bus_add_driver+0xd0/0x250
    [<c022a884>] driver_register+0x9c/0x128
    [<c00086bc>] do_one_initcall+0x90/0x160
    [<c06d1904>] kernel_init+0xe8/0x1a4
    [<c000ee4c>] kernel_thread_exit+0x0/0x8
    [<ffffffff>] 0xffffffff

Change-Id: I3b29d71463af849a072cabbe56637adf6db6d0da
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: sd: Set the card removed if card detect fails

Currently, the card state is not being set as removed, even
when the card is actually removed. We still wait for the
next request to fail and then check the error and set the
card to be removed.

With the new runtime-pm in place, the card device would be
removed on physical removal of card and the corresponding
parent would be suspended as well. Hence, when the queue is
flushed during clean-up, mmc_rpm_hold would be invoked,
which would fail, since the runtime-pm was disabled when the
card device was removed. Thus, it won't resume the card/host/
platform device. The request would continue and since the
controller is in suspended state nasty things would happen.

This patch sets the card as removed during mmc_sd_detect
itself, so that when a clean-up of queue happens during
card removal, it is known that the card has been removed
and the request is errored out there itself.

Change-Id: Id5022f8d7db43750edf137d4293796615b56ae36
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>