msm: cpufreq: Relax constraints on "msm-cpufreq" workqueue

This workqueue is not used in memory reclaim paths, so the
WQ_MEM_RECLAIM flag is not needed. Additionally, there is no
need to restrict the queue to having one in-flight work item.
Remove these constraints.

Change-Id: I9edde40917d3ec885ce061133de20680634321d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Ensure cpufreq change happens on corresponding CPU

Checking the cpus_allowed mask of the current thread before changing the
frequency doesn't guarantee that the rest of the execution will continue
on the same CPU. The only way to guarantee this is to schedule a work on
the specific CPU and also prevent hotplug of that CPU (already done by
existing code).

Change-Id: I51a02fcc777a47d3c16f2d83c47e96f2c59f7ae6
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes

When new values are written to scaling_min/max_freq sysfs files, the
current code applies all the limits imposed by various ADJUST and
INCOMPATIBLE notifiers handlers before storing them.

When the ADJUST and/or INCOMPATIBLE notifiers change their limits
frequently, this behavior makes it almost impossible for a
user/userspace process to store the scaling_min/max_freq limits
that go beyond the instantaneous limits imposed by the notifiers.
Since these sysfs nodes are typically meant to set limits that need
to be enforced for the foreseeable future, this is not a very user
friendly behavior.

So, change the behavior to only apply limits that are enforced by
the cpufreq driver. Typically, these are just the absolute limits
of the HW and don't change very often.

Change-Id: I1ccfaa2d1ee4ea595f882485d359dbdb407a0176
Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org>
msm: cpufreq: Merge CAF and fix hotcpu_notifier
Kernel Version: AK.045-FAUX.017b2-PRIMA