Revert "cpufreq: force cpuN policy to match cpu0 when changing freq or gov"

This reverts commit 21f4f8c935d4386df22bd900495043aff368b9d5.

* suspect causing issues
mdnie lite control: add initial control interface (version 1.3)

Version 1.3: updated sysfs interface
Version 1.2: fixed compatibility with samsung NA6 (kitkat) source.

available channels:
[/sys/class/mdnie/mdnie/*]
(* = red, green, blue, cyan, magenta, yellow, white, black)

set values for each channel:
[echo x y z > /sys/class/mdnie/mdnie/red]
(x = red; y = green; z = blue)
- range: 0-255

control for "sharpen" effect:
[echo x > /sys/class/mdnie/mdnie/sharpen]
- range: 0-11

override for all samsung modes and profiles:
[echo x > /sys/class/mdnie/mdnie/override]
- 0 = disabled
- 1 = enabled

copy color profile from existing mdnie profile:
[echo x > /sys/class/mdnie/mdnie/copy_mode]
- 0 = Standard
- 1 = Natural
- 2 = Movie

copy gamma curve from existing mdnie profile:
[echo x > /sys/class/mdnie/mdnie/gamma_curve]
- 0 = Movie
- 1 = Dynamic

Idea based on (mDNIe colour and brightness control) by AndreiLux.
Thanks to Yank555.lu for his hijack and mode copy implementation.

Signed-off-by: Wootever <Wootever@users.noreply.github.com>
sensorhub: eliminate SSP log spam

sensorhub code is such a mess
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>

Conflicts:

	drivers/cpufreq/cpufreq.c