Linux 3.4.60

Change-Id: I6f36d8e9e3b15b5a806e38bdfc8482e53fde7291
Linux 3.4.61

Change-Id: I77cc0c29337c5fd61475a0b8a7d0091c7189abc0
Linux 3.4.62

Change-Id: If1080f5a64778a77531790c3dab9059626cf7ea8
cpufreq: properly sync current scaling governor across all cores.

Previously (like a lot of CAF based kernels) the cpu governor, when changed would only
be applied to whatever cores were online at the time. This corrects that behavior.

Change-Id: Ieff1cdea24586b85a4fb72df52405101a8859217
[BACKPORT]: cpufreq: Fix governor start/stop race condition

Cpufreq governor's stop and start operation should be kept in sequence.
If not, there will be unexpected behavior, for example:

There are 4 CPUs and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
The normal sequence is as below:

1) Current governor is userspace, One application tries to set
governor to ondemand. It will call __cpufreq_set_policy in which it
will stop userspace governor and then start ondemand governor.

2) Current governor is userspace, Now cpu0 hotplugs in cpu3, It will
call cpufreq_add_policy_cpu in which it first stops userspace
governor, and then starts userspace governor.

Now if the sequence of above two cases interleaves, It becames
below sequence:

1) Application stops userspace governor
2) Hotplug stops userspace governor
3) Application starts ondemand governor
4) Hotplug starts a governor

In step 4, hotplug is supposed to start userspace governor, But now
the governor has been changed by application to ondemand, So hotplug
starts ondemand governor again !!!!

The solution is: Do not allow stop one policy's governor multi-times.
Governor stop should only do once for one policy, After it is stopped,
No other governor stop should be executed. also add one mutext to
protect __cpufreq_governor so governor operation can be kept in sequence.

Signed-off-by: Xiaoguang Chen <chenxg [at] marvell>

(Cherry-Picked from upstream Linux 3.11.0)

Change-Id: I09b0b88527c88ad3133b796f6eb478afd05dfdf1
cpufreq: Fix printing of governor and driver name the correct way.

Manually merged from Linux 3.11.0

Change-Id: I61c5d1baae4c7d1a78f39340482651337d714ac6
acpuclock-8064: more aggressive L2 cache overclock

Change-Id: Ic54929bf814214b3800681130b214502f3fe7091