cpufreq: interactive: Record hispeed_validated_time in timer function

Change 0cd554ae585f5ccbb95056e049a8fec0f0742dce
(cpufreq: interactive: Exercise hispeed settings at a policy level)
introduced policy level hispeed settings. The change is correct in
general, but it sets hispeed_validate_time after actual frequency
change has completed. Waking up speedchange task and setting
frequency takes non-trival amount of time. This period is not accounted
for in above_hispeed_delay, resulting in additional delays when
ramping up frequency. Frequency switch latency varies a lot
depending on beginning and end frequency, and thus it cannot be easily
compensated by user setting above_hispeed_delay.

Record a local hispeed_validated_time in every CPU's timer function.
Cluster hispeed_validated_time is the local hispeed_validated_time of
CPUs voting for the highest frequency.

Change-Id: Id8ae547fe3a70f8710f60b6e2125954111b7a2b6
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Fix a build error
cpufreq: interactive: don't skip waking up speedchange_task if target_freq > policy->cur

When __cpufreq_driver_target() in speedchange_task failed for some reason, the
policy->cur could be lower than the target_freq. The governor misses to change
the target_freq if the target_freq is equal to the next_freq at the next sample
time.

Added a check to prevent the CPU to stay at the speed that is lower than the
target_freq for long duration.

Change-Id: Ibfdcd193b8280390b8f8374a63218aa31267f310
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
Sync with newvidc
cpufreq: interactive : return value correction