cpufreq: interactive: Use frequency dependent per cpu timings

This allows in-depth testing of the timer routine.

Change-Id: I59023eb7e7758730ddc4b073087b46aa117e3a41
[zwliew: structural changes for unadulterated timer routine]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Honor boosted state when entering idle

The old logic didn't take the boosted state in account. Just
leave the comment intact because our temporary min is not
the regular policy->min it refers to.
cpufreq: interactive: fix compiling warnings
cpufreq: interactive: Initialize spinlocks

These were missing in commit 8fbac318173082918312d6a4ceacf63376797c52,
"cpufreq: interactive: Use frequency dependent per cpu timings".
cpufreq: Introduce new relation for freq selection

Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance
to target. In case of equal distance between 2 frequencies,
it will select the greater freq.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
cpufreq: interactive: use stratosk's method of calculating new freq

Change-Id: Ibadc149d9e16e8ea9a08384b9646c42516f6b493
net: Fix "ip rule delete table 256"

[ Upstream commit 13eb2ab2d33c57ebddc57437a7d341995fc9138c ]

When trying to delete a table >= 256 using iproute2 the local table
will be deleted.
The table id is specified as a netlink attribute when it needs more then
8 bits and iproute2 then sets the table field to RT_TABLE_UNSPEC (0).
Preconditions to matching the table id in the rule delete code
doesn't seem to take the "table id in netlink attribute" into condition
so the frh_get_table helper function never gets to do its job when
matching against current rule.
Use the helper function twice instead of peaking at the table value directly.

Originally reported at: http://bugs.debian.org/724783

Reported-by: Nicolas HICHER <nhicher@avencall.com>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cpuboost: Add hotplug boosting

If we decide to hotplug a core then we are making a strong
statement that we think that the system load is high.  Let's
have faith in our hotplug driver(s) and boost the cpufreq
when we are hotplugging cores.

Change-Id: Id992f225f89fab0507e20082fd0d32307550d2c1
cpufreq: cpu-boost: Increase sync thread policy and priority

More or less all cpufreq related threads run in a high priority.

Also, CMs patch series was somehow out of sync and incomplete,
readd the unchanged policy update to source cpu bit. And readd
the check for a possible corner case in try_to_wake_up() that
was already missing before.

Change-Id: Ibcc45217ff4b9323178b077754c4bb7c468984db
[zwliew: only increase priority]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Move definition of cpufreq_gov_interactive downwards

This moves definition of cpufreq_gov_interactive towards the bottom of file, so
that we don't have to add prototype of cpufreq_governor_interactive() in the
beginning of file.

Change-Id: I04bd1004954eb36502c5cd7e35d3d7274cddaf95
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>