Reduce logspam

Signed-off-by: MassStash <MassStash@gmail.com>
DRIVERS: SLIMBUS: slimbus enhancements mkII

This time we keep the root freq to 11.
If Root Freq is set at 11, 24,576MHz has the best compatibility for all present sampling rates (e.g, any sample rate can be converted, 48KHz to 96KHz, 44.1KHz to 96KHz, 48KHz to 128KHz etc.) Increasing the root frequency is likely to cause invalid present sample rate combinations which leads to audio glitches such as distortion. "A Natural Frequency is defined as a CLK frequency that allows a family of data rates to be supported. The different sample rate flows can be optimally supported by changing a particular Natural Frequency using the Clock Gear." I looked at a Clock Gear/RF table and it looks like CLK Gear 10 and RF 24,576MHz (Stock RF) is an excellent combination due to its compatibility towards every other sample rates.

ZeroInfinity/Poondog

Signed-off-by: ZeroInfinity <infinitezero345@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
DRIVERS: SLIMBUS: some more tweaks, which is double what we had before. According to some documents this is what we want for optimium audio quality

ZeroInfinity/Poondog

Signed-off-by: ZeroInfinity <infinitezero345@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
update defconfig

Conflicts:
	arch/arm/configs/elementalx_defconfig
Update built by branding

Signed-off-by: MassStash <MassStash@gmail.com>
optimize slub

Signed-off-by: MassStash <MassStash@gmail.com>
LOAD_FREQ to (4*HZ+61)

Signed-off-by: MassStash <MassStash@gmail.com>
disable gentle fair sleepers for better performance on android

Signed-off-by: MassStash <MassStash@gmail.com>
make vfs pressure configurable

Signed-off-by: MassStash <MassStash@gmail.com>
optimize slub

Signed-off-by: MassStash <MassStash@gmail.com>
vfp optimization

Signed-off-by: MassStash <MassStash@gmail.com>
vfp optimization

Signed-off-by: MassStash <MassStash@gmail.com>
increase random number generator rate

Signed-off-by: MassStash <MassStash@gmail.com>
avoid depleting of entropy pool

Signed-off-by: MassStash <MassStash@gmail.com>
glibc memcpy and stringcpy

Signed-off-by: MassStash <MassStash@gmail.com>
ARM: net: JIT compiler for packet filters enabled by default

Conflicts:
	arch/arm/boot/kernel
allow pipe compiling
optimize slack
cpufreq: cpu-boost: Fix deadlock in wake_up of sync threads

If wake_up() is called on the current task on a CPU, the call will wait
until the current task is switched out before it wakes it up again and
returns.

The sync notifier for a CPU always runs on that CPU.

These two together can result in a deadlock if the sync notifier on CPU A
tries to wake up the sync thread of CPU A as it goes to sleep (is the
current task). A previous commit fixed this by adding a check to the sync
notifier to not wake up the sync thread of CPU A if it's the current task.

But this is still not sufficient to prevent deadlocks.

Sync thread of CPU A could be the current task on CPU B and sync thread of
CPU B could be the current task on CPU A.  At this point, if sync notifier
of CPU A and B try to wake up the sync threads of CPU A and B, it will
result in CPU A waiting for the current task in CPU B to get switched out
and CPU B waiting for the current task in CPU A to get switched out.  This
will result in a deadlock.

Prevent this scenario from happening by pinning the sync threads of each
CPU to run on that CPU. By doing this, we guarantee that sync notifiers
will only try to wake up sync threads running on that CPU. The fix added by
"cpufreq: cpu-boost: Resolve deadlock when waking up sync thread" ensures a
deadlock doesn't happen when a sync notifier tries to wake up a sync thread
running on that CPU.

Change-Id: I864e545529722a23886dd5a82f66089155d2d193
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>
cpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplug

Calling queue_delayed_work_on() on a CPU that's in the process of getting
hotplugged out can result in that CPU infinitely looping in
msm_pm_wait_cpu_shutdown(). If queue_delayed_work_on() is called after the
CPU is hotplugged out, it could wake up the CPU without going through the
hotplug path and cause instability. To avoid this, make sure the CPU is and
stays online while queuing a work on it.

Change-Id: I1b4aae3db803e476b1a7676d08f495c1f38bb154
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>