Revert "mako_hotplug: fix some bugs, increase load levels by 10% each, queue the works in a dedicated workqueue, reduce the number of divisions every work call, fix a possible memory leak."

This reverts commit 9509bf7ddabe8501f1765a2c0f6392c3c999248f.
Revert "Add custom Mako Hotplug driver for onlining and offlining cores based on system load."

This reverts commit fd744c2cca0f5222461314043a15696b36c5c242.
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: Derek Cannata <thederekjay@gmail.com>
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Conflicts:
	block/Kconfig.iosched
	block/Makefile
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
cpufreq: msm: remove gov_mutex from stop

The stop could end up calling set_frequency callback. The set_frequency
callback takes the same gov_mutex lock and we end up in a deadlock.

Fix this by removing the locks around stop.

Change-Id: Ic687d92825f253aa3e23e4bcaf3c96d5879d4b43
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
cpufreq: msm: fix race in cpufreq

__cpufreq_driver_target expects to be called with the rw semaphore
held. We are not doing this when the frequency is asked to be changed
by dcvs.

Use cpufreq_driver_target variant of that function which gets the
rw semaphore before setting the frequency.

Change-Id: I67a7d437f68749f43c26b95ae73f436890326019
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
ext4: prevent kernel panic in case of uninitialized jinode

In some cases the kernel crash occurs during system suspend/resume:

[ 4095.041351] Unable to handle kernel NULL pointer dereference at
virtual address 00000000 [ 4095.050689] pgd = c0004000
[ 4095.053985] [00000000] *pgd=00000000
[ 4095.058807] Internal error: Oops: 5 [#1] PREEMPT SMP
[ 4095.064483] Modules linked in: wl12xx mac80211 pvrsrvkm_sgx540_120
cfg80211 compat [last unloaded: wl12xx_sdio] [ 4095.064575] CPU: 1
Tainted: G    B        (3.0.31-01807-gfac16a0 #1) [ 4095.064605] PC is
at jbd2_journal_file_inode+0x38/0x118 [ 4095.064666] LR is at
mpage_da_map_and_submit+0x48c/0x618 [ 4095.064697] pc : [<c01da5a8>]
lr : [<c01aeac0>]    psr: 60000013 [ 4095.064697] sp : c6e07c80  ip :
c6e07ca0  fp : c6e07c9c [ 4095.064727] r10: 00000001  r9 : c6e06000  r8
: 00000179 [ 4095.064758] r7 : c6e07ca0  r6 : c73b8400  r5 : 00000000
r4 : c59a7d80 [ 4095.064758] r3 : 00000038  r2 : 00000800  r1 : 00000000
 r0 : c7754fc0 [ 4095.064788] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32
 ISA ARM  Segment kernel [ 4095.064819] Control: 10c5387d  Table:
86cc804a  DAC: 00000015 [ 4095.064849]
[ 4095.064849] PC: 0xc01da528:
[ 4095.064880] a528  0a000003 e3a05000 e1a00005 e24bd020 e89da9f0
e5951010 e3e06000 e14b22dc
.....
[ 4095.070373] 7fe0: c00a48ac 00000013 00000000 c6e07ff8 c00a48ac
c00c0a94 84752f09 60772177 [ 4095.070404] Backtrace:
[ 4095.070465] [<c01da570>] (jbd2_journal_file_inode+0x0/0x118) from
[<c01aeac0>] (mpage_da_map_and_submit+0x48c/0x618) [ 4095.070495]
r7:c6e07ca0 r6:c6e07d00 r5:c6e07d90 r4:c7754fc0 [ 4095.070556]
[<c01ae634>] (mpage_da_map_and_submit+0x0/0x618) from [<c01af40c>]
(ext4_da_writepages+0x2a4/0x5c8) [ 4095.070617] [<c01af168>]
(ext4_da_writepages+0x0/0x5c8) from [<c0112af4>]
(do_writepages+0x34/0x40) [ 4095.070678] [<c0112ac0>]
(do_writepages+0x0/0x40) from [<c01645a4>]
(writeback_single_inode+0xd4/0x288) [ 4095.070709] [<c01644d0>]
(writeback_single_inode+0x0/0x288) from [<c0164ed4>]
(writeback_sb_inodes+0xb4/0x184) [ 4095.070770] [<c0164e20>]
(writeback_sb_inodes+0x0/0x184) from [<c01655a0>]
(writeback_inodes_wb+0xc4/0x13c) [ 4095.070831] [<c01654dc>]
(writeback_inodes_wb+0x0/0x13c) from [<c01658f0>]
(wb_writeback+0x2d8/0x464) [ 4095.070861] [<c0165618>]
(wb_writeback+0x0/0x464) from [<c0165cb8>] (wb_do_writeback+0x23c/0x2c4)
[ 4095.070922] [<c0165a7c>] (wb_do_writeback+0x0/0x2c4) from
[<c0165df4>] (bdi_writeback_thread+0xb4/0x2dc) [ 4095.070953]
[<c0165d40>] (bdi_writeback_thread+0x0/0x2dc) from [<c00c0b18>]
(kthread+0x90/0x98) [ 4095.071014] [<c00c0a88>] (kthread+0x0/0x98) from
[<c00a48ac>] (do_exit+0x0/0x72c) [ 4095.071044]  r7:00000013 r6:c00a48ac
r5:c00c0a88 r4:c78c7ec4 [ 4095.071105] Code: e89da8f0 e5963000 e3130002
1afffffa (e5913000) [ 4095.071166] ---[ end trace 7fe9f9b727e5cf78 ]---
[ 4095.071197] Kernel panic - not syncing: Fatal exception

The probably reason of such behaviour is an inode opened in READ mode
has been marked as 'dirty' somehow and written back by
ext4_da_writepages. Cause jinode == NULL it could lead to the kernel
panic.

The patch prevents kernel panic and helps to investigate the problem
providing an inode number.

Change-Id: I1d77a011b580db682b8e2d122ef3d5e44e0ce5c7
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
Restrict slave mountspace so Dalvik apps can mount system-wide volumes

Android 4.2 implements multi-user storage using per-process mount
namespaces.  Everything under "/" (the entire filesystem hierarchy) is
marked as a recursive-slave mountspace for all zygote instances.  This
is done so that user-storage sandbox mounts under /storage/emulated are
hidden from other apps and users.

Unfortunately this means that any Dalvik app (actually, any program
whose clone/fork ancestry includes a Dalvik zygote, which is everything
except services spawned directly from init) cannot mount system-wide
volumes. Thus, apps like CifsManager are effectively broken in Android
4.2, since its cifs mounts are only visible to the CifsManager app
itself.  All other apps see empty mountpoints instead of the mounted
volume.  Furthermore, Linux provides no provision for a process to
"escape" a recursive-slave mountspace in versions prior to Linux 3.8
(setns syscall).

Here, we restrict rootfs-slave calls to /storage (and, due to a possible
kernel bug, /mnt/shell/emulated) so that Dalvik apps can mount
system-wide volumes elsewhere (with appropriate permission, as in
earlier versions of Android), while retaining full multi-user storage
compatibility.  It is made available as a kernel-based workaround for
instances where libdvm can not be modified.

This change requires that a tmpfs volume is mounted as /storage in
init.rc. If this volume is unavailable, then we falls back to the
previous behavior of marking the entire filesystem hierarchy as slave.
arm: Add auto hotplug driver

This driver is simple and cheap and aims to avoid unnecessary hotplug
events and unnecessary task migrations. The design is simple. The value
of nr_running() (which is the current number of runnable threads) is
averaged over X samples by a ringbuffer. If the value is over a
dynamically calculated value, all CPUs are onlined. When the value falls
under another dynamically calculated value, the CPUs are offlined with a
2 second delay. If there is persistent load on the system, the CPUs will
not continually thrash between onlining and offlining and continually
migrate tasks. The number of online CPUs will remain constant until the
load has dropped below the dynamically calculated value. The online and
offline values are dynamically scaled based on the number of CPUs
online, as is the sampling rate of the driver. This aims to reduce the
expense of the driver and also reduce the number of unless hotplug
transitions which could have been avoided had cpufreq been given the
chance to ramp the online CPUs up and deal with the load. This driver
will also offline secondary cores when the screen is turned off,
providing earlysuspend is available.

It also has a module param to set
the minimum number of online CPUs:
/sys/module/auto_hotplug/parameters/min_online_cpus
This value is ignored when the device enters earlysuspend, as the
secondary CPUs are all offlined, but is set again when the screen is
turned back on.

Conflicts:
	arch/arm/kernel/auto_hotplug.c
auto_hotplug: Enhanced version
gamma_control: Adjust contrast to my preference.

Signed-off-by: Derek Cannata <thederekjay@gmail.com>
hsic: Restore autosuspend values.
drivers: input: touch filter control enablement

1) Turn off accuracy filter by default and add a switch to turn it
on. Since it is off by default, users with issues should be fixed I
hope.  Good practice will be to turn off, set params, and turn on to
that the touchscreen is not disrupted if the user is interacting with
it.

To enable:
echo 1 > /sys/devices/virtual/input/lge_touch/accuracy_filter_enable

To disable:
echo 0 > /sys/devices/virtual/input/lge_touch/accuracy_filter_enable

2) Allow stock defaults to be set on init so when a user decides they
want to enable the filter, they will have reasonable defaults ready to
go.

3) TESTING ONLY - Allow Jitter filter control to be turned on in a
similar way and allow the adjust_margin parameter to be adjusted.  I
thought this might be useful for stylus control or users with big hands
etc, but after initial testing it doesn't seem to be useful at all and
makes the touch screen very hard to use. We will leave in for more
testing for now. Will likely pull unless it proves to be useful for some
purpose.

/sys/devices/virtual/input/lge_touch/adust_margin
/sys/devices/virtual/input/lge_touch/jitter_filter_enable

Notes: The stock kernel already allows all these parameters to be set in
one command as below. These recent changes initiated by Franco opens
each component up so that apps/scripts can more easily read the
variables. Since we add the ability to read by component, it makes sense
to also allow write by component and makes it easier to understand what
variables are being adjusted.

echo "accuracy_filter_enable ignore_pressure_gap delta_max
touch_max_count max_pressure direction_count time_to_max_pressure" >
/sys/devices/virtual/input/lge_touch/accuracy/sys/devices/virtual/input/lge_touch/accuracy

echo "jitter_filter_enable adjust_margin" >
/sys/devices/virtual/input/lge_touch/accuracy/sys/devices/virtual/input/lge_touch/jitter
Conflicts:
	drivers/input/touchscreen/lge_touch_core.c
cpufreq/cpufreq_intellidemand: [SQAUSHED] intellidemand cpufreq governor

Intellidemand is inspired by ondemand governor. Its main features are:

 - auto cpu hotplugging based on runnable thread average calculations
 - detection of browsing mode (long screen on activities with moderate run
   queue depth =< 45 )
 - limit max frequencies when in browsing mode to conserve battery for long
   duration tasks

Browsing State Determination:
 1- Browsing state is enabled as power-on default. Browsing state is disabled
    when run queue depth is > 45 (very high instantaneous spikes)

Browsing State Limit Max Freq Logic (sliding window algorithm):
 1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then
    CPU Max frequencies will remain power-on default
 2- While Screen is On, if average CPU load > 35%, both CPUs max frequencies
    will be limited to a lower user configurable max value
 3- While Screen is On, After both CPUs' Max is limited to lowered max, when
    the average CPU load has dropped down to less than < 25%, then both CPUs
    Max freq will be restored to back to power-on default

Runnable Thread Auto-hotplug (fast hotplug / slow unplug algorithm):
 1- When average number of running thread is < threshold, 2nd cpu will be
    unplugged.
 2- When > threshold, 2nd cpu will be hotplugged.
 3- The logic applies a fast hotplug and slow unplug algorithm so 2nd core
    will stay enabled longer to help deal with performance spikes

changes from Ver 2.0 -> Ver 3.0:
  - remove GPU Busy dependency for browsing state detection (this will make
    the governor more portable to other platforms without specific GPU
    architecture knowledge)

dependencies:
  -- Qualcomm's run queue average logic (SOC independent logic)
  -- TI's runnable thread average logic (SOC independent logic)

forward ported to Linux 3.4 for use on Mako

Signed-off-by: faux123 <reioux@gmail.com>