acpuclock-7627.c: fixing table selection in select_freq_plan()

In the function 'select_freq_plan()' there's a check to select
the correct table for 1008Mhz CPU's, because there's a conflict
between 7627AA and 8625 chips.

However this check is wrong:
	if (pll_mhz[ACPU_PLL_2] == 245)

It should be:
	if (pll_mhz[ACPU_PLL_1] == 245)

We don't want to check PLL_2 but PLL_1 being '245' or not.

Due of this bug the wrong frequency table is getting selected
for 1GHz 8625 chips with PLL_2=245.

Previously-detected-by: Peter Jung <peter.jung@lge.com>
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
block: *fixing CAF merge derp*

CAF did apply following patches:

2012-02-08: "block: separate out blk_rq_merge_ok() and blk_try_merge() from elevator functions" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=050c8ea80e3e90019d9e981c6a117ef614e882ed)

After that they applied:

2012-05-24: "block: ioctl support for sanitize in eMMC 4.5" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=73937f5face75e05ec2a72966d04f4e20aa18379)
(this commit if faulty already after the commit from 2012-02-08!)

And then they merged:

2012-06-07: "Merge commit 'AU_LINUX_ANDROID_ICS.04.00.04.00.126' into msm-3.4" (https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/block/elevator.c?h=msm-3.4&id=f132c6cf77251e011e1dad0ec88c0b1fda16d5aa)
(this totally screwed the patch from 2012-02-08)

Now it's fixed and like it's supposed like :-)

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
drivers/cpufreq: conservative: simplify SAMPLING_TIME determination for ARM

...because simple things can be good things, too.

This commit introduces MIN_SAMPLING_RATE & DEF_SAMPLING_RATE
which are used to directly set the driver's minimum and default
sampling rate rather than doing any calculation before.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
binfmt_elf.c: use get_random_int() to fix entropy depleting.

Usually the entropy pool depletes very fast and stays in the 100-200 range.
After this patch, the entropy stays in the 600-1000 range without the risk of
depleting in normal workloads.

Change-Id: Ice0d0f14691046249d7b4a4d31af98ab80c6306b
huawei_battery.c: reduced charging voltage from 4350 mV to 4300 mV

...to prevent overcharging and increasing battery's longevity.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
huawei_battery.c: increase RPC polling from 5sec to 60sec

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
huawei_battery.c: decrease BATTERY_HIGH_HIGH & HEALTH_HIGH_VOLT_MAX to 4350

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
msm: rq_stats: move away from tick-sched

IMHO tick-sched is the wrong place for this piece of code. The only thing
which needs to be done in there is to call (void update_rq_stats()).

Let's move update_rq_stats() and wakeup_user() into arch/arm/mach-msm/msm_rq_stats.c

Since wakeup_user() is called unconditionally and doesn't seem to be needed
elsewhere, get rid of this function and migrate it to update_rq_stats().

To avoid possible conflicts and to make clear where 'update_rq_stats' belongs
to we rename it into 'msm_update_rq_stats'.

On this opportunity we also define msm-rq-stats internal declarations as static.

And for the case we disable those rq-stats one day (we will for sure!) add
some ifdef's within tick-sched.c

Signed-off-by: moddingg33k <moddingg33k@t-online.de>

Conflicts:

	arch/arm/mach-msm/msm_rq_stats.c