PM / Sleep: Do not check wakeup too often in try_to_freeze_tasks()

Use the observation that it is more efficient to check the wakeup
variable once before the loop reporting tasks that were not
frozen in try_to_freeze_tasks() than to do that in every step of that
loop.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

Conflicts:

	kernel/power/process.c

Signed-off-by: Srivalli Oguri <oguri@codeaurora.org>
(cherry picked from commit a15cc22b56b803b8f943c57d9535bdb9953ff3ec)

Change-Id: Ic41cd71a0ec49cd0c633c14aa3fce02025a4de3f
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
earlysuspend: block userspace until late resume completes

Currently the late_resume function runs in a workqueue that is
triggered when the /sys/power/state is changed when the screen
is turned on. The problem this causes is that userspace sets
/sys/power/state to turn the screen on and after
request_suspend_state() returns userspace expects that the
kernel is ready to receive backlight adjustments, however
the backlight driver may not have finished its late_resume()
function yet, because the late_resume workqueue is still running.
Therefore we can get brightness requests before the backlight
driver late_resume function has completed and during the
resume sequence which can cause for undesired backlight
brightness results.

The solution for this is to have the late_resume functions run
within the context of the user space process that triggered the
screen on event. So that the request_suspend_state('wakeup')
function doesn't return until all the late_resume functions
have been completed. And therefore, userspace doesn't send
backlight (and other) requests to the kernel drivers before
they are all resumed.

Signed-off-by: Joe Swantek <w98568@motorola.com>