cpufreq: ondemand: Remove input boost

A probably imperfect extermination of ondemand's input boost.
We rely on the universal cpu boost input handler now.

Change-Id: If4e0669920c6f2ce25f088a2e88adfb89858856b
cpufreq: ondemand: Remove sync thread feature

Syncing threads in the cpu-boost driver is sufficient.

Change-Id: I6b3f17b01b0ef6765f7de952aff329c77c781735
msm: mdss: Use interruptible wait to not affect load average

Change-Id: I7ad6644ca49e8f4d30ede9076dd1854a19614570
selinux: Fix Kernel panic due to NULL pointer dereference

Below Kernel panic is observed due to race condition, where
sock_has_perm called in a thread and is trying to access sksec->sid
without checking sksec. Just before that, sk->sk_security was set
to NULL by selinux_sk_free_security through sk_free in other thread.

31704.949269:   <3> IPv4: Attempt to release alive inet socket dd81b200
31704.959049:   <1> Unable to handle kernel NULL pointer dereference at \
                        virtual address 00000000
31704.983562:   <1> pgd = c6b74000
31704.985248:   <1> [00000000] *pgd=00000000
31704.996591:   <0> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
31705.001016:   <6> Modules linked in: adsprpc [last unloaded: wlan]
31705.006659:   <6> CPU: 1    Tainted: G           O  \
                        (3.4.0-g837ab9b-00003-g6bcd9c6 #1)
31705.014042:   <6> PC is at sock_has_perm+0x58/0xd4
31705.018292:   <6> LR is at sock_has_perm+0x58/0xd4
31705.022546:   <6> pc : [<c0341e8c>]    lr : [<c0341e8c>]    \
                                                  psr: 60000013
31705.022549:   <6> sp : dda27f00  ip : 00000000  fp : 5f36fc84
31705.034002:   <6> r10: 00004000  r9 : 0000009d  r8 : e8c2b700
31705.039211:   <6> r7 : dda27f24  r6 : dd81b200  r5 : 00000000  \
                                                  r4 : 00000000
31705.045721:   <6> r3 : 00000000  r2 : dda27ef8  r1 : 00000000  \
                                                  r0 : dda27f54
31705.052232:   <6> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM \
                        Segment user
31705.059349:   <6> Control: 10c5787d  Table: 10d7406a  DAC: 00000015
.
.
.
.
31705.697816:   <6> [<c0341e8c>] (sock_has_perm+0x58/0xd4) from \
                    [<c033ed10>] (security_socket_getsockopt+0x14/0x1c)
31705.707534:   <6> [<c033ed10>] (security_socket_getsockopt+0x14/0x1c) \
                           from [<c0745c18>] (sys_getsockopt+0x34/0xa8)
31705.717343:   <6> [<c0745c18>] (sys_getsockopt+0x34/0xa8) from \
                    [<c0106140>] (ret_fast_syscall+0x0/0x30)
31705.726193:   <0> Code: e59832e8 e5933058 e5939004 ebfac736 (e5953000)
31705.732635:   <4> ---[ end trace 22889004dafd87bd ]---

Change-Id: I79c3fb525f35ea2494d53788788cd71a38a32d6b
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
defconfig: Regenerate

* Disable /dev/diag
* Disable unused stuff
* Enable HIDRAW for wiimote pairing support
* Significantly improve latencies while leaving debug
  and logging intact

Change-Id: I6cc54461e91e46a1e76ae2a1fdb57dec3ecb4488
cpufreq: interactive: Add max_freq_hysteresis feature

Previously known as sampling down factor, max_freq_hysteresis
extends the period that interactive governor will stay at policy->max.
This feature is to accomodate short idle periods in an otherwise very
intensive workload.

When the feature is enabled, it ensures that once a CPU goes to max
frequency, it doesn't reduce the frequency for max_freq_hysteresis
microseconds from the time it first goes to idle.

Change-Id: Ia54985cb554f63f8c22d0b554a0a0f2ed2be038f
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Make window alignment optional

Make sampling window alignment optional when scheduler inputs
are not enabled.

Change-Id: If69c111a3efe219cdd1e38c1f46f03404789c0bb
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Exercise hispeed settings at a policy level

If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.

To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.

Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.

Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.

Change-Id: I1749d663949e34753ecb5c426a16563796f8b0b2
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Merge remote-tracking branch 'cm-12.0/cm-12.0' into HEAD