qcom-cpufreq: Remove use of device_suspended in the hotplug path

The CPU_DOWN_PREPARE notifier in cpufreq.c already takes care
of performing a CPUFREQ_GOV_STOP, which waits for in-progress
frequency switches to complete and prevents any additional
frequency switches from being performed. Remove the redundant
code for accomplishing the same thing from qcom-cpufreq.

Besides being good cleanup, this change should also resolve
a potential deadlock in out-of-memory conditions. The scenario
arises if CPU1, executing in msm_cpufreq_target(), holds the
qcom-cpufreq suspend_mutex while waiting for the completion
at the end of that same function. In an out-of-memory condition,
the work performing that completion may not be able to
immediately run.

At the same time, CPU2 may be executing CPU_DOWN_PREPARE hotplug
notifiers. It will be holding the global hotplug mutex at this
time, and will eventually become blocked in
msm_cpufreq_cpu_callback() while waiting for the CPU1 to release
the device_suspended lock.

If invoked, the out-of-memory killer will attempt to acquire
the hotplug mutex via get_online_cpus() as part of
out_of_memory().  This lock is already held by CPU2. CPU2 will
not release the lock until the device_suspended lock is released
by CPU1. The device_suspended lock will not be release until the
completion in msm_cpufreq_target() is marked as complete, which
won't happen until the out-of-memory killer is able to free
some memory. Nasty deadlock.

Clearly, the out-of-memory condition itself needs to be resolved,
but there is no harm in resolving the deadlock also.

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