msm: don't compile MSM_RUN_QUEUE_STATS.

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

defconfig: Disable CONFIG_MSM_RUN_QUEUE_STATS

Signed-off-by: ayysir <dresadd09691@gmail.com>
Support for display gamma control

Originally written by Paul Reioux (faux123)

Modified from his original implementation as follows:
* Remove kgamma_ctrl sysfs entry - it did absolutely nothing
* Alter the show() functions to output the checksum in the
first entry, in order to match the expected input of
the store() functions.  This should not break existing
applications
* Move store/show code to a common function
* Add limit checks from Mike Cain (motley)
* Added a kgamma_apply sysfs entry which will apply
  the current state when anything is stored to it,
  instead of waiting until the next time the LCD
  is power cycled

Change-Id: I8835e42709cefa547e02e28a7e5a381d88282700
Undervolt

Undervolt: clean it up, make it elegant and remove the constrain of fixed set of NUM_FREQS - its not dynamic based on the number of freqs used for scaling via an external function.

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

Undervolt: add checks to disallow too extreme voltages, min and max.

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

Undervolt: few minor changes, mostly for clarity.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Mako (absolute) Voltage control.

This started out as just including the existing work of someone else.
But that was so obfuscated and needlessly moved in sysfs, i turned it into the type control
we have on NP, meaning same sysfs location and output formatting.
Since the various kernels range from no preUV to different levels of UV it is best to encourage the user
to think in absolute voltages.
"I can UV -150 on kernel X! Really? Odd, i can only UV kernel Y -50mV!"
Kernel X has no preUV, kernel Y has 100mV preUV, so they both run the same.
This is needlessly confusing to users.

Talking in absolutes, users will get a better understanding of "what the other guy's" device is capable of.
Sticking to a common sysfs location and to the common absolute voltage is thus the right thing to do.

This seems to work now as it should.

This is heavily based on coolbho3k's NP patch. from Paul's mess we might have a few function names, but not the contents.
This is not his, if he claims otherwise, he can go fuck himself.

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

Conflicts:
	arch/arm/mach-msm/Kconfig
FK: dt2w

drivers: input: major improvements on the doubletap to wake feature.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
drivers: input: add a mechanism to wake the device by either double tapping the display or swipping from wherever you want. The device deep sleeps but the digitizer is still powered on, otherwise it couldn't detect touch events. Battery usage should be little to minimal, but I haven't ran any numbers.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Readahead: Optimize divide/multiply by power of 2 using L/R shift - Fix
scripts: remove localversion "+" from kernel version strings
Signed-off-by: faux123 <reioux@gmail.com>
modules: bypass vermagic check for  TouchControl module.

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

module: also bypass bad_version check.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
arm/crypto: Add optimized AES and SHA1 routines

Add assembler versions of AES and SHA1 for ARM platforms.  This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.

Platform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement

IXP425      533 MHz      big     11217042        15566294        ~38%
KS8695      166 MHz     little    3828549         5795373        ~51%

Signed-off-by: David McCullough <ucdevel@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
defconfig: bringup #3 + TC
ondemand gov: fixup

cpufreq: ondemand: Fix hotplug deadlock with store_powersave_bias

store_powersave_bias() acquires the hotplug lock and the dbs_mutex
lock, but does so in the wrong order.  Deadlocks like the following
can result.

Thread A:
    get_online_cpus+0x3c/0x5c           <- acquires 'cpu_hotplug.lock'
    store_powersave_bias+0x80/0x3f4     <- acquires 'dbs_mutex'
    kobj_attr_store+0x14/0x20
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Thread B:
    cpufreq_governor_dbs+0x7c/0x55c     <- acquires 'dbs_mutex'
    __cpufreq_governor+0x90/0xe0
    __cpufreq_set_policy+0x1b0/0x258
    cpufreq_add_dev_interface+0x2cc/0x334
    cpufreq_add_dev+0x514/0x580
    cpufreq_cpu_callback+0x88/0x9c
    notifier_call_chain+0x38/0x68
    __cpu_notify+0x28/0x40
    _cpu_up+0xe4/0x118                  <- acquires 'cpu_hotplug.lock'
    cpu_up+0x64/0x80
    store_online+0x48/0x78
    dev_attr_store+0x18/0x24
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Fix this by flipping the order in which the locks are acquired and
released in store_powersave_bias so that it is the same as in the
hotplug path.

Change-Id: Idc59fb29d60b8f7fceb8ed0f2bb9eff4670abda7
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix locking issue in store_powersave_bias

store_powersave_bias takes timer_mutex before calling dbs_timer_exit
which tries to cancel the delayed work do_dbs_timer which in turn
tries to take the same lock. This can cause a lock recursion under
the race condition where can cancel_delayed_work_sync is called
when the work has already started executing.

This can be avoided by taking that lock after calling
dbs_timer_exit.

Change-Id: I7f862286e66f1ddc1e13e4eeee369dd188fc10d5
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: ondemand: Fix locking in store_powersave_bias

store_powersave_bias() assumes that dbs_info->cur_policy will
not change while it is executing. If it does, memory corruption
can potentially result. Fix this by acquiring the dbs_lock.

Most noticeably, this resolves timer-related list corruptions
encountered when queue_delayed_work_on() is called from within
store_powersave_bias() while a CPU is being hotplugged in and
out.

CRs-Fixed: 494407
Change-Id: I0fd5cbef6834545274cad9481e574ec50b37b871
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix store_powersave_bias() race with hotplug

store_powersave_bias() assumes that CPUs will not be taken offline or
brought online while executing its for_each_online_cpu() loops. Fix
this race by blocking hotplug while executing in these loop.

CRs-Fixed: 494407
Change-Id: I0d5520444ec21a8d9b12fb73c06ac8442449fa85
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix update_sampling_rate race with hotplug

update_sampling_rate has a for loop which goes through each
online cpu and possibly queue up the ondemand work for them.
But while doing this it doesnt take any hotplug lock which
could potentially cause a race condition where ondemand work
is queued after the hotplug code (which sets the policy to NULL)
in the governor has cancelled any pending work. This could cause
a crash while trying to access the NULL policy in dbs_check_cpu.

Protecting the for_each_online_cpu loop with get_online_cpus()
and put_online_cpus().

Change-Id: Ia3f43ca7e4bed542834ab03ca1191d728f13311c
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
binfmt_elf.c: use get_random_int() to fix entropy depleting

Changes:
--------
v4->v3:
- s/random_stack_user()/get_atrandom_bytes()/
- Move this function to ahead of its use to avoid the predeclaration.

v3->v2:
- Tweak code comments of random_stack_user().
- Remove redundant bits mask and shift upon the random variable.

v2->v1:
- Fix random copy to check up buffer length that are not 4-byte multiples.

v3 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59597.html
v2 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59418.html
v1 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59128.html

Thanks,
-Jeff

Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc...  between 2.6.30 to current mainline, for instance:

$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620

We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").

/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));

The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.

With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878

Analyzed by John Sobecki.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnn@arndb.de>
Cc: John Sobecki <john.sobecki@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: mdm2: Decrease leakage before QSC power-up

Cleanup of IPC gpios for driver strength and toggle
AP2MDM_STATUS only after AP2MDM_KPD_PWR is toggled, this
will decrease the leakage from MSM to QSC before QSC
powering up.

CRs-Fixed: 460500
Change-Id: Iabfa34331b613dd66577e485572a809440cf5272
Signed-off-by: Taniya Das <tdas@codeaurora.org>

modified for Mako use

Signed-off-by: Paul Reioux <reioux@gmail.com>
net: flow: Prevent bringing up new CPUs during per-CPU initialization

In a rare race-condition, it's possible that a CPU will be brought
online between when the for_each_online_cpu() loop executes to
call flow_cache_cpu_prepare(), and when the hotplug notifier for
calling this same function is registered. If this happens,
flow_cache_cpu_prepare() will never be called for the new CPU,
resulting in crashes due to uninitialized per-cpu data.

Fix this by preventing CPUs from being added or removed during
this small but sensitive window.

Change-Id: Iafbbaa8a50e5c527392d130561874313720849d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: Manage only online cpus

cpufreq core doesn't manage offline cpus and if driver->init() has returned
mask including offline cpus, it may result in unwanted behavior by cpufreq core
or governors.

We need to get only online cpus in this mask. There are two places to fix this
mask, cpufreq core and cpufreq driver. It makes sense to do this at common place
and hence is done in core.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mach-msm: subsystem_restart: Fix CPU detection

Initialization function could not detect the correct CPU type
(apq8064). Therefore it could not register correctly subsystem
restart order for the panic_handler.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).
drivers: msm_thermal: make thermal throttle temperature threshold user configurable.

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

drivers: thermal: properly limit CPU frequency when the temperature is too hot: if we throttle too much games will lag so we'll only scale down to 1026MHz until the device cools down, then back to 1512MHz again. Added other smaller routine changes to make it work properly.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
thermal: tsens8960: Increase the polling rate

Change the polling rate at which the sensors temperature
is read from 1 second to .25 seconds. On faster parts
there is a need to poll the temperature at a higher
frequency to improve reporting temperature changes.

Change-Id: I10049707c3e55316597fff72fbd00246cd29bed3
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
board: mako: reduce the minimum backlight value to 0x01.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
kernel: cgroup_timer_slack: Adaptations for 3.4 kernel

Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cgroups: timer_slack: forward port timer_slack to 3.4. http://lwn.net/Articles/431847/

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