msm: vidc: flush queued work during device suspend

This change flushes any queued work related to power collapse,
once the device is power suspended.
There are applications which do not destroy video instance
on suspending the device. For such applications, if the device
is power suspended, video driver does not prepare venus for
power collapse.
Considerable power saving is observed by power collapsing
venus before the device goes in suspend state.

Change-Id: I11252e45b10d0d3d3eefb38994acd083c847bbb8
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: vidc: reduce clk frquency before disable

The change ensures that the clock frequency is reduced to min
before we disable it.
With just clk_disable, rpm still votes for high voltage on CX
as venus vote is not removed.
To unvote, the frequency is set to min.

CRs-Fixed: 574365
Change-Id: I8e0515b9816f8c451d545443573afaba611aafe7
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Consider changed min limit a frequency boost

A changed policy->min can safely be considered a frequency boost.
Process this change analogous to the cpufreq_interactive_boost()
routine.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Honor boosted state in several timer calculations

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Support variable frequency calculations

Use a threshold value up to which we are evaluating the current
speed weighted by current load against each new choice of speed.
Above switch to the original frequency calculation proportional to
load relative to the max possible frequency which allows for more
dynamic and fair changes.

Default threshold is cpuinfo min which guarantees minimal freqs
and energy usage during (offloaded) media playback.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: fix race between try_to_wake_up() and move_task()

Until a task's state has been seen as interruptible/uninterruptible
and it is no longer on_cpu, it is possible that the task may move
to another CPU (load balancing may cause this). Here is an example
where the race condition results in incorrect operation:

- cpu 0 calls put_prev_task on task A, task A's state is TASK_RUNNING
- cpu 0 runs task B, which attempts to wake up A
- cpu 0 begins try_to_wake_up(), recording src_cpu for task A as cpu 0
- cpu 1 then pulls task A (perhaps due to idle balance)
- cpu 1 runs task A, which then sleeps, becoming INTERRUPTIBLE
- cpu 0 continues in try_to_wake_up(), thinking task A's previous
  cpu is 0, where it is actually 1
- if select_task_rq returns cpu 0, task A will be woken up on cpu 0
  without properly updating its cpu to 0 in set_task_cpu()

CRs-Fixed: 665958
Change-Id: Icee004cb320bd8edfc772d9f74e670a9d4978a99
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: move task load based functions

The task load based functions will need to make use of LOAD_AVG_MAX
in a subsequent patch, so move them below the definition of that
macro.

Change-Id: I02f18ba069b81033e611f8f8bba6dccd7cd81252
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>