Revert "Variable GPU OC: sysfs interface to cycle through different top gpu speeds"

This reverts commit 675b521a1369f49e2527072bbb840b90fffe49da.
Added sysfs option to set screen_on_min_freq
With this option, the certain lack of smoothness can be counteracted when scaling_min_freq is set very low (e.g. to 192 MHz). Thanks to this option, battery savings granted by the low scaling_min_freq can be achieved, without any negative effects to the user.
The sysfs path is located at: /sys/devices/system/cpu/cpu0/cpufreq/screen_on_min_freq
arch: omap: add userspace export of the current GPU clock. Works mostly like scaling_cur_freq.
Source: https://github.com/franciscofranco/Tuna_JB_pre1/commit/a9c8946aef889caaed0f37c8caf475ccdece78f5
Variable GPU OC: sysfs interface to cycle through different top gpu speeds (by imoseyon) and set 384 MHz GPU speed as default.

- sysfs control path: /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
  0 = 307mhz, 1 = 384mhz, 2 = 512mhz

Source: https://github.com/edoko/AirKernel_GN_JB/commit/8f8698154d5424853e814f1b4cb8542a63780c6f

Note boype: Finally got it working properly after examining the code; also slightly adjusted GPU voltages so that the 512 MHz OPP gets a little more current than the 384 MHz OPP.
CPU transition latency: 30000; also optimized screen_on_min_freq behavior
Revert "change var naming to kernel standard way"

This reverts commit 729316019eeba08af143ee06f04d5f7d8a3b0ee5.
Revert "Change gamma caculation hack and top value."

This reverts commit 15bef2a979fd148453080253bb77a916386bcbfc.
Revert "Add voodoo multipliers stuff"

This reverts commit 92c03de547e9fd12140b2379cf7a200513b6ca5f.
Revert "Super Amoled color hack"

This reverts commit a016dc32b2e3b4ededbd181081256cf05728a4fd.
Added Color Control version 4.

Conflicts:

	drivers/misc/Kconfig
	drivers/misc/Makefile

Conflicts:

	drivers/misc/Kconfig
	drivers/misc/Makefile
Added Battery Life eXtender (BLX) version 1. - From Ezekeel

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

Conflicts:

	drivers/misc/Kconfig
	drivers/misc/Makefile
Added Sound Control version 1.

Conflicts:

	drivers/misc/Makefile
Added Custom Voltage version 3.

Conflicts:

	arch/arm/mach-omap2/omap2plus-cpufreq.c
	drivers/misc/Kconfig
	drivers/misc/Makefile
Add C4 state again since TI guys added it to omapzoom - big props to Ezekeel that discovered this patch before and TI used it on their own official tree.
Wifi sleep power mode sysfs
0 is PM_MAX (default), 1 is PM_FAST
path is /sys/module/bcmdhd/parameters/wifi_pm

original commit by KalimochoAz
adapted to Android 4.3 kernel by boype
Repair tuna kernel compilation missing label
omap44xx: cpuidle: Update target residencies to saner values

The current values are insane.

There is no possible way power saving
can be attained by heading into C4 for not much more than 1ms. The average
values are in the 20ms range, so why do we need to even entertain entering
at much lower values when we will use more power than we save in doing so.

The actual recommended values are shown in 79e796f7b993bd82ad108fa488c35ddd1b9387eb
but for some obscure reason, in 16385c726d55f9e84bbc60ff9e329a84d56a13a3 and
22e2193661b6bffcfdc1a4d17f6af0d1782ba860 they were updated to match the exit_latency.

This seems horribly wrong to me as there comes a point when the target residency is
so low that you use more power actually entering the state than you gain from the
insignificant amount of time you spend there.

With the values in this commit, C4 state is used for >95% of the time when the screen
is off, with C3 picking up the remainder.
During audio playback, C4 is used ~50% of the time, C3 is used ~25% of the time and C2
picks up whatever is left.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
My contrast control from ICS.
Asynchronous I/O latency to a solid-state disk greatly increased
between the 2.6.32 and 3.0 kernels. By removing the plug from
do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
lib/crc: add slice by 8 algorithm to crc32.c

Add support for slice by 8 to existing crc32 algorithm.  Also modify
gen_crc32table.c to only produce table entries that are actually used.
The parameters CRC_LE_BITS and CRC_BE_BITS determine the number of bits in
the input array that are processed during each step.  Generally the more
bits the faster the algorithm is but the more table data required.

Using an x86_64 Opteron machine running at 2100MHz the following table was
collected with a pre-warmed cache by computing the crc 1000 times on a
buffer of 4096 bytes.

BITS Size LE Cycles/byte BE Cycles/byte
----------------------------------------------
1 873 41.65 34.60
2 1097 25.43 29.61
4 1057 13.29 15.28
8 2913 7.13 8.19
32 9684 2.80 2.82
64 18178 1.53 1.53

BITS is the value of CRC_LE_BITS or CRC_BE_BITS. The old
default was 8 which actually selected the 32 bit algorithm. In
this version the value 8 is used to select the standard
8 bit algorithm and two new values: 32 and 64 are introduced
to select the slice by 4 and slice by 8 algorithms respectively.

Where Size is the size of crc32.o's text segment which includes
code and table data when both LE and BE versions are set to BITS.

The current version of crc32.c by default uses the slice by 4 algorithm
which requires about 2.8 cycles per byte.  The slice by 8 algorithm is
roughly 2X faster and enables packet processing at over 1GB/sec on a
typical 2-3GHz system.

Signed-off-by: Bob Pearson <rpearson@systemfabricworks.com>
Cc: Roland Dreier <roland@kernel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>