msm: hotplug: Consider load instead of frequency for slowest cpu

Signed-off-by: renderbroken <zkennedy87@gmail.com>
msm: rq_stats: Use cpufreq API to get the current frequency

Since the acpuclock APIs are deprecated, use the cpufreq to
get the current frequency of CPUs to calculate the cpu
normalized load value.

Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: rq_stats: Calculate load based on current freq limit

Prior to this patch, load has been calculated based on an initial
value of policy.cpuinfo.max_freq. This value may change for several
reasons: userspace settings, thermal throttling (hello hammerhead!)
or extended frequency tables where the absolute maximum level is
often not used during regular operations. This results in unreliable
calculations. Consider current policy.max to fix this behaviour.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: rq_stats: Disable hotplug and stats by default

Userspace closed source mpdecision binary is nessecary for PowerHAL to work.
As it depends on rq_stats, let's at least disable hotplugging and stats
collection by default. /sys/devices/system/cpu/cpu0/rq-stats/hotplug_disable
is now writable, so hotplug can be reenabled.

Also, add some bits related to current cpu policy.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Use u64 instead cputime64_t

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	arch/arm/mach-msm/msm_hotplug.c
	arch/arm/mach-msm/msm_rq_stats.c
	drivers/cpufreq/cpufreq_HYPER.c
	drivers/cpufreq/cpufreq_intelliactive.c
	drivers/cpufreq/cpufreq_interactive.c
	drivers/cpufreq/cpufreq_nightmare.c
	drivers/cpufreq/cpufreq_ondemand.c
	drivers/cpufreq/cpufreq_pegasusq.c

Signed-off-by: renderbroken <zkennedy87@gmail.com>
Ramdisk: Render Script: Configure interactive frequency dependent timings
In theory this should improve performance while conserving
a bit of energy and also help against jitter at the same time.

Signed-off-by: renderbroken <zkennedy87@gmail.com>
msm_rq_stats: Update for use with msm_hotplug
Signed-off-by: renderbroken <zkennedy87@gmail.com>
msm: cpufreq: Don't try to call acpuclk_get_rate()

acpuclk_get_rate() is broken, so don't even try to call it as it will
invoke clk_get_rate() anyway.
qcom-cpufreq: Move the enabling of the CPU/L2 clocks to CPU_STARTING

It is a requirement of PLLs in MSM SoCs that the PLL power
supplies be enabled while the PLL is running. If the PLL is
locked and outputs enabled, turning off the regulator(s)
supplying the PLL will cause the PLL to enter an unpredictable
state.

Now in the CPU_UP_PREPARE notifier, the CPU clocks are prepared
and enabled, causing the source HFPLLs to also turn on. Note
that the CPU isn't clocked yet. It is possible that execution is
pre-empted and the CPU running the notifier enters power
collapse. If all other CPUs also enter power collapse, then it
is possible for an RPM notification to go out, allowing the RPM
to transition the Apps processor to its sleep set. This can
result in the HFPLL supplies being turned off while the HFPLL is
running, violating the requirement mentioned above. Once the CPU
is unclamped, the CPU is effectively unclocked, due to the HFPLL
being in an unknown state.

There is a check that is enabled in the PM code's CPU_UP_PREPARE
notifier callback. This check ensures that the problematic RPM
notification cannot occur until the core that is being brought
online also enters power collapse. However, there is no ordering
guarantee between that PM's hotplug notifier callback's execution
and the cpufreq hotplug notifier callback's execution. This
ordering depends on program link order, which is unreliable.

It is necessary to ensure that once the HFPLL is enabled, the
RPM cannot transition apps to its sleep set. Move the enabling
of the CPU clocks to the CPU_STARTING notifier, which runs on
the CPU bring brought online. The CPU_STARTING notifier is
guaranteed to run after the CPU_UP_PREPARE notifier, which
implies that the aforementioned do-not-notify-rpm check is
executed *before* the HFPLL is enabled. Therefore even if all
cores enter power collapse after the HFPLL is enabled, the
HFPLL supplies are guaranteed to stay on, or the CPU clock
is switched to the safe source and the HFPLL is turned off.

CRs-Fixed: 622738
Change-Id: I136841405806c07e755919859e649ded0c719abb
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
qcom-cpufreq: Block hotplug until cpufreq is ready

Hotplug before qcom-cpufreq is ready could lead to inconsistent CPU
clock state. Block hotplug by returning NOTIFY_BAD in hotplug callback
until qcom-cpufreq is probed.

Change-Id: I72a2f98c083c9b21b95ecafdb5a5be7a7682e842
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
qcom-cpufreq: Fix hotplug blocking logic

Change 2b63b10 qcom-cpufreq: Block hotplug until cpufreq is ready
intended to block hotplug until qcom-cpufreq driver has got all
clocks. However, its implementation still leaves a small window when
CPU 0 has got its clock but others haven't. If a hotplug happens on
another CPU that doesn't have its clock pointer, refcount of that CPU
clock will again be wrong.

Fix the issue by introducing a ready flag.

Change-Id: I1e05b063b0584088f717b82709a3f1d55bc6561b
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
qcom-cpufreq: Fix frequency table registration

CPUfreq device is the provider of CPU frequency table, and
it should always keep track of freq tables for every CPU itself.
cpufreq_frequency_get_table() is an API for frequency table user.
qcom-cpufreq should not use this API to obtain CPU freq table in
the init function. Otherwise, the following sequence will lead to init
failure.

Assume CPU 0 and 1 are under control of same policy and online. Say
policy->cpu is CPU 0.

1) Hot unplug CPU0
   update_policy_cpu() will transfer ownership of policy to CPU1
   cpufreq_frequency_table_update_policy_cpu() is called during
   the process to set CPU1's freq table to be the same as CPU0's freq
   table. CPU0's freq table is now NULL.
2) Hot unplug CPU1
   All CPUs in policy are now offline.
3) Hot plug in CPU0
   cpufreq_driver->init() is called for initialization. If this init
   function calls cpufreq_frequency_get_table() on CPU0, the result
   will be NULL.

Current qcom-cpufreq checks return value of cpufreq_frequency_get_table()
and returns an error in init.

Remove the usage of cpufreq_frequency_get_table() and fill in frequency
table for policy->cpu in msm_cpufreq_init().

Change-Id: I2d41af776938c31b4444c9f280a341dd1bed1548
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Stash these, Dont remember what I had changed.lol