power/main: Optimize maximum frequency reset

Signed-off-by: cocafe <cocafehj@gmail.com>

Conflicts:
	kernel/power/main.c

Change-Id: I155301bc974a2ec0e7897ee21e23d63612272ec5
Revert "power/main: Optimize maximum frequency reset"

This reverts commit 7cc8154053bda74536d8badcd011f8f0f6ca4bb2.
power: Fake Samsung DVFS interfaces

To make Samsung DVFS App happy!

Signed-off-by: cocafe <cocafehj@gmail.com>
power/main: Optimize maximum frequency reset

Signed-off-by: cocafe <cocafehj@gmail.com>
interactive: Sync with android-kernel-common-3.0

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c

Change-Id: I118ffbab57e5a21ff1bb64a9d56a354a69b580f3
Revert "interactive: Sync with android-kernel-common-3.0"

This reverts commit 4de7fbbcdb346c2a06ed7ece8ad85e2126718bc1.
ARM: ux500: Add LiveOPP(OC/UC/OV/UV) supports

As I have said hundreds of times, modifying these useless numbers in frequency table
do not have any effect on overclocking. Run benchmarks will provide that clearly.

It goes: set arm_clk -> db8500 driver find matched frequency -> get matched frequency index ->
get matched ARM OPP -> set ARM OPP (An OPP contains Varm/PLLARM/ArmFixMGT etc etc)

We lack of proper document which explains PRCMU and AB8500 Regulator registers.
We guessed the meanings of these registers by searching the code and endless experiments.
So we can not make everything absolutely right.
But it is actually overclocked. Benchmarks spoke.

This patch is made for PRCMU Project U8500 MBL (Samsung Janice has) which has ARM MaxOPP.
For the deivces which do not have MaxOPP(1000MHz) by default, change ARM_MAX_OPP to ARM_100_OPP
in LiveOPP ARM table. 1000MHz for these devices is stable, and the higher frequencies may be unstable.
Thanks Robert Rozic@github for testing on Codina on the fly.

How to set ARMPLL has been explained in code.

All available overclocked frequencies are stable for Janice, 1228MHz is the maximum stable frequency.
1267MHz will cause Apps FC and reboot.

Signed-off-by: cocafe <cocafehj@gmail.com>
LiveOPP: Increase some voltage

Signed-off-by: cocafe <cocafehj@gmail.com>
ARM: ux500: Enable 100MHz for SD/SDIO/MMC devices

From: https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/arch/arm/mach-ux500/board-mop500-sdi.c?id=b6ff56a4acdc16c626f713bbad0528984234e550

MMCI fmax is 515633

Signed-off-by: cocafe <cocafehj@gmail.com>
mmc/mmci: Fix warning
sched: Remove CONFIG_SAMSUNG_ADD_GAFORENSICINFO

Samsung debugging stuff

Signed-off-by: cocafe <cocafehj@gmail.com>
lib/lzo: Optimize code for CPUs with inefficient unaligned access

Some code paths are only benefical on machines with fast unaligned
loads, so only use these if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
defined.

Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>

Conflicts:
	lib/lzo/lzo1x_compress.c
	lib/lzo/lzo1x_decompress.c
	lib/lzo/lzodefs.h

Change-Id: I5108d9ab8b9684bc8037b3e2e0d7683ff53d69df
Revert "lib/lzo: Optimize code for CPUs with inefficient unaligned access"

This reverts commit f1a90ef59cedcfb89cd2cd35841b2d9d869cab7f.
dvfs-dbg: Free the code

To debug the prcmu QoS requirements with new cpufreq table.

Signed-off-by: cocafe <cocafehj@gmail.com>

Conflicts:
	arch/arm/mach-ux500/dvfs-debug.c

Change-Id: I955138ccfc10d990e088071ca07ae714e1db426b
Revert "dvfs-dbg: Free the code"

This reverts commit 2efaa19686ef281a1444aa185d5334c658ba615a.
block: limit default readahead size for small devices

Linus reports a _really_ small & slow (505kB, 15kB/s) USB device,
on which blkid runs unpleasantly slow. He manages to optimize the blkid
reads down to 1kB+16kB, but still kernel read-ahead turns it into 48kB.

     lseek 0,    read 1024   => readahead 4 pages (start of file)
     lseek 1536, read 16384  => readahead 8 pages (page contiguous)

The readahead heuristics involved here are reasonable ones in general.
So it's good to fix blkid with fadvise(RANDOM), as Linus already did.

For the kernel part, Linus suggests:
  So maybe we could be less aggressive about read-ahead when the size of
  the device is small? Turning a 16kB read into a 64kB one is a big deal,
  when it's about 15% of the whole device!

This looks reasonable: smaller device tend to be slower (USB sticks as
well as micro/mobile/old hard disks).

Given that the non-rotational attribute is not always reported, we can
take disk size as a max readahead size hint. This patch uses a formula
that generates the following concrete limits:

        disk size    readahead size
     (scale by 4)      (scale by 2)
               1M                8k
               4M               16k
              16M               32k
              64M               64k
             256M              128k
        --------------------------- (*)
               1G              256k
               4G              512k
              16G             1024k
              64G             2048k
             256G             4096k
(*) Since the default readahead size is 128k, this limit only takes
effect for devices whose size is less than 256M.

The formula is determined on the following data, collected by script:

	#!/bin/sh

	# please make sure BDEV is not mounted or opened by others
	BDEV=sdb

	for rasize in 4 16 32 64 128 256 512 1024 2048 4096 8192
	do
		echo $rasize > /sys/block/$BDEV/queue/read_ahead_kb
		time dd if=/dev/$BDEV of=/dev/null bs=4k count=102400
	done
The principle is, the formula shall not limit readahead size to such a
degree that will impact some device's sequential read performance.

The Intel SSD is special in that its throughput increases steadily with
larger readahead size. However it may take years for Linux to increase
its default readahead size to 2MB, so we don't take it seriously in the
formula.

SSD 80G Intel x25-M SSDSA2M080 (reported by Li Shaohua)

	rasize	1st run		2nd run
	----------------------------------
	  4k	123 MB/s	122 MB/s
	 16k  	153 MB/s	153 MB/s
	 32k	161 MB/s	162 MB/s
	 64k	167 MB/s	168 MB/s
	128k	197 MB/s	197 MB/s
	256k	217 MB/s	217 MB/s
	512k	238 MB/s	234 MB/s
	  1M	251 MB/s	248 MB/s
	  2M	259 MB/s	257 MB/s
==>	  4M	269 MB/s	264 MB/s
	  8M	266 MB/s	266 MB/s
Note that ==> points to the readahead size that yields plateau throughput.

SSD 22G MARVELL SD88SA02 MP1F (reported by Jens Axboe)

	rasize  1st             2nd
	--------------------------------
	  4k     41 MB/s         41 MB/s
	 16k     85 MB/s         81 MB/s
	 32k    102 MB/s        109 MB/s
	 64k    125 MB/s        144 MB/s
	128k    183 MB/s        185 MB/s
	256k    216 MB/s        216 MB/s
	512k    216 MB/s        236 MB/s
	1024k   251 MB/s        252 MB/s
	  2M    258 MB/s        258 MB/s
==>       4M    266 MB/s        266 MB/s
	  8M    266 MB/s        266 MB/s
SSD 30G SanDisk SATA 5000

	  4k	29.6 MB/s	29.6 MB/s	29.6 MB/s
	 16k	52.1 MB/s	52.1 MB/s	52.1 MB/s
	 32k	61.5 MB/s	61.5 MB/s	61.5 MB/s
	 64k	67.2 MB/s	67.2 MB/s	67.1 MB/s
	128k	71.4 MB/s	71.3 MB/s	71.4 MB/s
	256k	73.4 MB/s	73.4 MB/s	73.3 MB/s
==>	512k	74.6 MB/s	74.6 MB/s	74.6 MB/s
	  1M	74.7 MB/s	74.6 MB/s	74.7 MB/s
	  2M	76.1 MB/s	74.6 MB/s	74.6 MB/s

USB stick 32G Teclast CoolFlash idVendor=1307, idProduct=0165

	  4k	7.9 MB/s 	7.9 MB/s 	7.9 MB/s
	 16k	17.9 MB/s	17.9 MB/s	17.9 MB/s
	 32k	24.5 MB/s	24.5 MB/s	24.5 MB/s
	 64k	28.7 MB/s	28.7 MB/s	28.7 MB/s
	128k	28.8 MB/s	28.9 MB/s	28.9 MB/s
==>	256k	30.5 MB/s	30.5 MB/s	30.5 MB/s
	512k	30.9 MB/s	31.0 MB/s	30.9 MB/s
	  1M	31.0 MB/s	30.9 MB/s	30.9 MB/s
	  2M	30.9 MB/s	30.9 MB/s	30.9 MB/s

USB stick 4G SanDisk  Cruzer idVendor=0781, idProduct=5151

	  4k	6.4 MB/s 	6.4 MB/s 	6.4 MB/s
	 16k	13.4 MB/s	13.4 MB/s	13.2 MB/s
	 32k	17.8 MB/s	17.9 MB/s	17.8 MB/s
	 64k	21.3 MB/s	21.3 MB/s	21.2 MB/s
	128k	21.4 MB/s	21.4 MB/s	21.4 MB/s
==>	256k	23.3 MB/s	23.2 MB/s	23.2 MB/s
	512k	23.3 MB/s	23.8 MB/s	23.4 MB/s
	  1M	23.8 MB/s	23.4 MB/s	23.3 MB/s
	  2M	23.4 MB/s	23.2 MB/s	23.4 MB/s

USB stick 2G idVendor=0204, idProduct=6025 SerialNumber: 08082005000113

	  4k	6.7 MB/s 	6.9 MB/s 	6.7 MB/s
	 16k	11.7 MB/s	11.7 MB/s	11.7 MB/s
	 32k	12.4 MB/s	12.4 MB/s	12.4 MB/s
   	 64k	13.4 MB/s	13.4 MB/s	13.4 MB/s
	128k	13.4 MB/s	13.4 MB/s	13.4 MB/s
==>	256k	13.6 MB/s	13.6 MB/s	13.6 MB/s
	512k	13.7 MB/s	13.7 MB/s	13.7 MB/s
	  1M	13.7 MB/s	13.7 MB/s	13.7 MB/s
	  2M	13.7 MB/s	13.7 MB/s	13.7 MB/s

64 MB, USB full speed (collected by Clemens Ladisch)
Bus 003 Device 003: ID 08ec:0011 M-Systems Flash Disk Pioneers DiskOnKey

	4KB:    139.339 s, 376 kB/s
	16KB:   81.0427 s, 647 kB/s
	32KB:   71.8513 s, 730 kB/s
==>	64KB:   67.3872 s, 778 kB/s
	128KB:  67.5434 s, 776 kB/s
	256KB:  65.9019 s, 796 kB/s
	512KB:  66.2282 s, 792 kB/s
	1024KB: 67.4632 s, 777 kB/s
	2048KB: 69.9759 s, 749 kB/s

An unnamed SD card (Yakui):

         4k     195.873 s,  5.5 MB/s
         8k     123.425 s,  8.7 MB/s
         16k    86.6425 s, 12.4 MB/s
         32k    66.7519 s, 16.1 MB/s
==>      64k    58.5262 s, 18.3 MB/s
         128k   59.3847 s, 18.1 MB/s
         256k   59.3188 s, 18.1 MB/s
         512k   59.0218 s, 18.2 MB/s

CC: Li Shaohua <shaohua.li@intel.com>
CC: Clemens Ladisch <clemens@ladisch.de>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Acked-by: Rik van Riel <riel@redhat.com>
Tested-by: Vivek Goyal <vgoyal@redhat.com>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
ondemandq: Remove CPU idle detection

Signed-off-by: cocafe <cocafehj@gmail.com>
pegasusq: Decrease default scaling up threshold

To make it more sensitive.
ondemand: Decrese up threshold 95 -> 75

With DVFS disabled, freq scaling depends on the governor we use.
I don't want to enable touch booster, so I decide to modify governors.
Up threshold @75 is nice.
ondemandq: Decrease up threshold 95 -> 75

Signed-off-by: cocafe <cocafehj@gmail.com>