frandom:  Added to build
Squash Linux 3.4.1-10

Linux 3.4.1

Linux 3.4.2

Conflicts:
	fs/ext4/mballoc.c
	fs/ext4/namei.c

Linux 3.4.3

Linux 3.4.4

Linux 3.4.5

Linux 3.4.6

Linux 3.4.7

Conflicts:
	mm/vmscan.c

Linux 3.4.8

Conflicts:
	fs/ext4/extents.c
	fs/ext4/super.c

Linux 3.4.9

Linux 3.4.10
I think this should be disabled with the OC stuff I brought in
Squash Linux 3.4.11-20

Linux 3.4.11

Linux 3.4.12

Conflicts:
	arch/arm/include/asm/mutex.h
	mm/vmscan.c

Linux 3.4.13

Linux 3.4.14

Linux 3.4.15

Linux 3.4.16

Linux 3.4.17

Linux 3.4.18

Linux 3.4.19

Linux 3.4.20
Squash Linux 3.4.21-30

Linux 3.4.21

Linux 3.4.22

Linux 3.4.23

Linux 3.4.24

Linux 3.4.25

Conflicts:
	include/linux/freezer.h

Linux 3.4.26

Linux 3.4.27

Linux 3.4.28

Linux 3.4.29

Conflicts:
	arch/arm/mm/dma-mapping.c

Linux 3.4.30
Squash Linux 3.4.31-40

Linux 3.4.31

Linux 3.4.32

Linux 3.4.33

Linux 3.4.34

Linux 3.4.35

Linux 3.4.36

Linux 3.4.37

Linux 3.4.38

Linux 3.4.39

Linux 3.4.40
Squash Linux 3.4.41-50

Linux 3.4.41

Linux 3.4.42

Conflicts:
	kernel/sched/core.c

Linux 3.4.43

Linux 3.4.44

Linux 3.4.45

Linux 3.4.46

Linux 3.4.47

Linux 3.4.48

Linux 3.4.49

Linux 3.4.50
Fix up some mis-merges from Linux merge
Squash Linux 3.4.51-60

Linux 3.4.51

Linux 3.4.52

Linux 3.4.53

Linux 3.4.54

Linux 3.4.55

Linux 3.4.56

Linux 3.4.57

Linux 3.4.58

Linux 3.4.59

Conflicts:
	kernel/futex.c

Linux 3.4.60

Conflicts:
	kernel/workqueue.c
Fix derp
Squash Linux 3.4.61-70

Linux 3.4.61

Linux 3.4.62

Linux 3.4.63

Linux 3.4.64

Linux 3.4.65

Linux 3.4.66

Linux 3.4.67

Linux 3.4.68

Linux 3.4.69

Linux 3.4.70
Squash Linux 3.4.71-80

Linux 3.4.71

Linux 3.4.72

Linux 3.4.73

Conflicts:
	block/elevator.c

Linux 3.4.74

Linux 3.4.75

Linux 3.4.76

Linux 3.4.77

Conflicts:
	arch/arm/kernel/traps.c
	drivers/net/ethernet/broadcom/tg3.c

Linux 3.4.78

Linux 3.4.79

Linux 3.4.80
Squash Linux 3.4.81-83

Linux 3.4.81

Linux 3.4.82

Linux 3.4.83

Conflicts:
	arch/arm/mm/proc-v7.S
	mm/memory_hotplug.c
	mm/vmscan.c

Conflicts:
	mm/memory_hotplug.c
Enable CPU under-clocking
Bump kernel version and re-enable stock thermal
cpufreq: Save user policy min/max instead of policy min/max during hotplug

When a CPU is hotplugged off, various fields of the policy are saved so
that they can be restored when the CPU is hotplugged back in.

The existing code saves the policy min/max field during hotplug remove and
restores it into user policy min/max during hotplug add. This results in
the loss of the user policy min/max values across a hotplug remove/add.

Fix it by saving the user policy min/max instead of policy min/max during
hotplug remove. During a hotplug add, after user policy min/max is
restored, the policy min/max is already recomputed. So, there's no risk of
going beyound any limits imposed by the CPUFREQ_ADJUST/INCOMPATIBLE
notifiers.

Change-Id: Ib8e09fa324c1f80f095c5754b5dcf2685e8e4a66
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: Fix policy getting stuck when user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max has
some overlap with the current policy min/max. This works out fine until we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check at
the start of __cpufreq_set_policy fails and prevents us from getting out of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: ondemand: fix timer-related list corruption in store_powersave_bias()

The dbs_timer_init() call in store_powersave_bias() re-initializes the
dbs_info workqueue, call on dbs_timer_exit() to ensure
outstanding work is cleared prior to making this call. Also, grab the
percpu timer_mutex lock to avoid race conditions with respect to the
dbs timer.

Change-Id: I79f3d43eeb51d2d8e21edd0fe043d6583333951f
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
ondemand: add sysfs entry for down_diff_multi_core

This change adds sysfs entry for the ondemand governor's attribute
down_differential_multi_core. This is required to be able to program
this knob to attain better perf/power for use cases like camcorder.

CRs-fixed: 561456
Change-Id: Ib7c1223215c6b714c286c231ed37f3abfae741c6
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
cpufreq: ondemand: Remove unnecessary synchronization attempt

Commit 1ce28d6b (ondemand: updated tune for hardware coordination)
brings in an attempt to synchronize expiry of per-cpu ondemand timer
at same time across all online cpus. This is meant to help systems
where "multiple cores share P-state via Hardware Coordination".

Synchronization is achieved by having timers expire when jiffy value
would be a perfect multiple of sampling window size. While such
synchronozation attemps are unnecessary on systems where cores don't
share P-states, it can hurt on power as cpus can now work off shorter
sampling windows (when percentage utilization over short window can be
observed to be high, causing frequency to be boosted).

Remove this unnecessary attempt to synchronize expiry of ondemand
timer across online cpus. A more acceptable solution could be to have
low-level architecture specific cpufreq driver indicate the need for
synchronization.

Change-Id: I6cb1cf3472ca106f029dc01248e0df7cfbb495b8
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>