sched/cpuidle: reduce IPI store. Backport upstream 3.16 scheduler updates

Change-Id: I54d698e6e1f0ca67709f2b1f8dc12909d396f2b2
Signed-off-by: Paul Reioux <reioux@gmail.com>
sched: fix race between try_to_wake_up() and move_task()

Until a task's state has been seen as interruptible/uninterruptible
and it is no longer on_cpu, it is possible that the task may move
to another CPU (load balancing may cause this). Here is an example
where the race condition results in incorrect operation:

- cpu 0 calls put_prev_task on task A, task A's state is TASK_RUNNING
- cpu 0 runs task B, which attempts to wake up A
- cpu 0 begins try_to_wake_up(), recording src_cpu for task A as cpu 0
- cpu 1 then pulls task A (perhaps due to idle balance)
- cpu 1 runs task A, which then sleeps, becoming INTERRUPTIBLE
- cpu 0 continues in try_to_wake_up(), thinking task A's previous
  cpu is 0, where it is actually 1
- if select_task_rq returns cpu 0, task A will be woken up on cpu 0
  without properly updating its cpu to 0 in set_task_cpu()

CRs-Fixed: 665958
Change-Id: Icee004cb320bd8edfc772d9f74e670a9d4978a99
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ext4: Add support for FIDTRIM, a best-effort ioctl for deep discard trim

* What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, We want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
 - blocks reassigned by the FS prior to FIDTRIM.

Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e
Signed-off-by: Geremy Condra <gcondra@google.com>
Signed-off-by: JP Abgrall <jpa@google.com>
cpufreq: Introduce new relation for freq selection

Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance
to target. In case of equal distance between 2 frequencies,
it will select the greater freq.

Change-Id: Iec6623f3b72f99504d704b95719af0e3b0ade728
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: mdss: Fix issues in gamma interface

Protect access to panel command struct by mutex,
this should help with ULPS stability during panel
on as well.  Also, remove the broken debug FS.

Change-Id: I3add31a5bc1cc22341e9bab3c688ed57b5b62993
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
lz4: add overrun checks to lz4_uncompress_unknownoutputsize()

Jan points out that I forgot to make the needed fixes to the
lz4_uncompress_unknownoutputsize() function to mirror the changes done
in lz4_decompress() with regards to potential pointer overflows.

The only in-kernel user of this function is the zram code, which only
takes data from a valid compressed buffer that it made itself, so it's
not a big issue.  But due to external kernel modules using this
function, it's better to be safe here.

Change-Id: I395a7de92e188bdcfd6378df469e56ac68de49d0
Reported-by: Jan Beulich <JBeulich@suse.com>
Cc: "Don A. Bailey" <donb@securitymouse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Added fsync on/off support.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
fs: sync: enable fsync by default.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
fs: sync: add missing return if fsync is disabled from userspace.

Change-Id: Ia6df0b292b6b366db0ec4bb9727d1c4839ab9a02
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
init: debug: bye bye

Change-Id: I4beb4ce6054e6c06f178e9b9495008991acccbc8
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm_mpdecision: Back off just a tad

* Currently this is too aggressive just by a tad.  Let's hold this back a bit and give a little bit more space for cpu governors to work their magic before engaging more cores.

Change-Id: Ieaad3841e7231a9efc746438783122d287ac8aab
Signed-off-by: Chet Kener <Cl3Kener@gmail.com>