cpufreq/ondemand: add default values for new ondemand parameters

Signed-off-by: faux123 <reioux@gmail.com>
cpufreq/ondemand: set default sampling rate to 50k for battery savings

Signed-off-by: faux123 <reioux@gmail.com>
sched: fix rq->lock recursion

Enabling SCHED_HRTICK currently results in rq->lock recursion and a hard
hang at bootup.  Essentially try_to_wakeup() grabs rq->lock and tries
arming a hrtimer via hrtimer_restart(), which deep down tries waking up
ksoftirqd, which leads to a recursive call to try_to_wakeup() and thus
attempt to take rq->lock recursively!!

This is fixed by having scheduler queue hrtimer via
__hrtimer_start_range_ns() which avoids waking up ksoftirqd.

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Change-Id: I11a13be1d9db3a749614ccf3d4f5fb7bf6f18fa1
thermal: pm8xxx-tm: Modify userspace notification method

Change the userspace notification mechanism in the over
temperature interrupt handler from kobject_uevent() to
sysfs_notify() in order to simplify userspace notification
handling.  Ensure that the new notification mechanism is
independent from the current pm8xxx-tm mode.  This means that the
"mode" thermalfs file does not need to be modified in order for
sysfs_notify() to get called in the interrupt handler.

As before, writing "enabled" to mode will enable the software
override of the automatic PMIC hardware stage 2 partial shutdown
and stage 3 full shutdown.  Turning off these features is
typically undesirable and should be avoided unless userspace is
able to take immediate corrective action.

Change-Id: Ibd92b790778fd559df5ce74231e6cf71bef16370
Signed-off-by: David Collins <collinsd@codeaurora.org>
thermal: pm8xxx-tm: Improve temp alarm logging and notification filtering

Modify the kernel log message which is output when the PMIC
temperature alarm triggers so that the current (or estimated)
PMIC die temperature is shown regardless of ADC type.

Also change the log message printing and userspace notification
logic so that they only happen when the PMIC temp alarm stage
differs from what was previously seen.  This will reduce the
number of messages seen while the temperature fluctuates around
one of the thresholds.

Change-Id: I5ee2206ea05dee86666308d11dad1fc5560e58e0
Signed-off-by: David Collins <collinsd@codeaurora.org>
thermal: pm8xxx-tm: Use delayed_work task for temp alarm status reading

Use a delayed_work task to wait at least 40 ms in order for the
temp alarm status value to be updated after the TEMP_STAT IRQ
goes high.  Also remove IRQ enable and disable calls in the ISR
since the work item can only be enqueued once before it is run.

Change-Id: Ib5f13d0e82258b399749de96152c081d71981909
Signed-off-by: David Collins <collinsd@codeaurora.org>

Conflicts:

	drivers/thermal/pm8xxx-tm.c
thermal: pm8xxx-tm: Add configuration option for allowing shutdown override

Add a field to the PMIC thermal alarm core data named
allow_software_override which is used to control whether or not
userspace may switch the mode of a PMIC thermal device to
"enabled" in order to enable software override of PMIC automatic
over temperature shutdown.

allow_software_override -
true:  writing "enabled" to thermalfs mode file results in
       software override of PMIC automatic over temperature
       shutdown.
false: PMIC automatic over temperature shutdown is always
       enabled.  mode file cannot be set to "enabled".

Change-Id: I4c47fdf0c0c4704008591755296118ad7fac95ae
Signed-off-by: David Collins <collinsd@codeaurora.org>
thermal: pm8xxx-tm: Configure temperature alarm for always-on operation

Change the register initialization for the PMIC temperature alarm
module so that it is always on.  This ensures that die
temperature monitoring is active even if CXO is disabled (i.e.
when sleep_b is low).  This is necessary since CXO can be
disabled while the system is still heavily loaded.  Also, using
the alway-on instead of PWM-enabled configuration ensures that
the die temperature can be measured by the PMIC ADC without
reconfiguring the temperature alarm module first.

Change-Id: I4a76c959c81f222fbeca08b6c98b1e4b23653b4e
Signed-off-by: David Collins <collinsd@codeaurora.org>
sched: track the runnable average on a per-task entity basis

Instead of tracking averaging the load parented by a cfs_rq, we can track
entity load directly.  With the load for a given cfs_rq then being the sum of
its children.

To do this we represent the historical contribution to runnable average within
each trailing 1024us of execution as the coefficients of a geometric series.

We can express this for a given task t as:
  runnable_sum(t) = \Sum u_i * y^i, runnable_avg_period(t) = \Sum 1024 * y^i
  load(t) = weight_t * runnable_sum(t) / runnable_avg_period(t)

Where: u_i is the usage in the last i`th 1024us period (approximately 1ms) ~ms
and y is chosen such that y^k = 1/2.  We currently choose k to be 32 which
roughly translates to about a sched period.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: maintain per-rq runnable averages

Since runqueues do not have a corresponding sched_entity we instead embed a
sched_avg structure directly.

Signed-off-by: Ben Segall <bsegall@google.com>
Reviewed-by: Paul Turner <pjt@google.com>
modified for Mako kernel from kernel.org

Signed-off-by: faux123 <reioux@gmail.com>
sched: aggregate load contributed by task entities on
 parenting cfs_rq

For a given task t, we can compute its contribution to load as:
  task_load(t) = runnable_avg(t) * weight(t)

On a parenting cfs_rq we can then aggregate
  runnable_load(cfs_rq) = \Sum task_load(t), for all runnable children t

Maintain this bottom up, with task entities adding their contributed load to
the parenting cfs_rq sum.  When a task entity's load changes we add the same
delta to the maintained sum.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: maintain the load contribution of blocked entities

We are currently maintaining:
  runnable_load(cfs_rq) = \Sum task_load(t)

For all running children t of cfs_rq.  While this can be naturally updated for
tasks in a runnable state (as they are scheduled); this does not account for
the load contributed by blocked task entities.

This can be solved by introducing a separate accounting for blocked load:
  blocked_load(cfs_rq) = \Sum runnable(b) * weight(b)

Obviously we do not want to iterate over all blocked entities to account for
their decay, we instead observe that:
  runnable_load(t) = \Sum p_i*y^i

and that to account for an additional idle period we only need to compute:
  y*runnable_load(t).

This means that we can compute all blocked entities at once by evaluating:
  blocked_load(cfs_rq)` = y * blocked_load(cfs_rq)

Finally we maintain a decay counter so that when a sleeping entity re-awakens
we can determine how much of its load should be removed from the blocked sum.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: add an rq migration call-back to sched_class

Since we are now doing bottom up load accumulation we need explicit
notification when a task has been re-parented so that the old hierarchy can be
updated.

Adds: migrate_task_rq(struct task_struct *p, int next_cpu)

(The alternative is to do this out of __set_task_cpu, but it was suggested that
this would be a cleaner encapsulation.)

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: account for blocked load waking back up

When a running entity blocks we migrate its tracked load to
cfs_rq->blocked_runnable_avg.  In the sleep case this occurs while holding
rq->lock and so is a natural transition.  Wake-ups however, are potentially
asynchronous in the presence of migration and so special care must be taken.

We use an atomic counter to track such migrated load, taking care to match this
with the previously introduced decay counters so that we don't migrate too much
load.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: aggregate total task_group load

Maintain a global running sum of the average load seen on each cfs_rq belonging
to each task group so that it may be used in calculating an appropriate
shares:weight distribution.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: compute load contribution by a group entity

Unlike task entities who have a fixed weight, group entities instead own a
fraction of their parenting task_group's shares as their contributed weight.

Compute this fraction so that we can correctly account hierarchies and shared
entity nodes.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: normalize tg load contributions against runnable time

Entities of equal weight should receive equitable distribution of cpu time.
This is challenging in the case of a task_group's shares as execution may be
occurring on multiple cpus simultaneously.

To handle this we divide up the shares into weights proportionate with the load
on each cfs_rq.  This does not however, account for the fact that the sum of
the parts may be less than one cpu and so we need to normalize:
  load(tg) = min(runnable_avg(tg), 1) * tg->shares
Where runnable_avg is the aggregate time in which the task_group had runnable
children.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>.
sched: maintain runnable averages across throttled periods

With bandwidth control tracked entities may cease execution according to user
specified bandwidth limits.  Charging this time as either throttled or blocked
however, is incorrect and would falsely skew in either direction.

What we actually want is for any throttled periods to be "invisible" to
load-tracking as they are removed from the system for that interval and
contribute normally otherwise.

Do this by moderating the progression of time to omit any periods in which the
entity belonged to a throttled hierarchy.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: replace update_shares weight distribution with per-entity computation

Now that the machinery in place is in place to compute contributed load in a
bottom up fashion; replace the shares distribution code within update_shares()
accordingly.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>
sched: refactor update_shares_cpu() -> update_blocked_avgs()

Now that running entities maintain their own load-averages the work we must do
in update_shares() is largely restricted to the periodic decay of blocked
entities.  This allows us to be a little less pessimistic regarding our
occupancy on rq->lock and the associated rq->clock updates required.

Signed-off-by: Paul Turner <pjt@google.com>
Reviewed-by: Ben Segall <bsegall@google.com>