ZenX: Add ZenX governor, zeneractive v2.
Changes over Zeneractive:
- The hackiness of total_below/above_unplug_time arrays got the axe. Now we actually set and use the data set on each CPU as we should have all along.
- Ditto last_time_above/below_unplug_time
- We now calculate the average load across _all_ ONLINE CPUs instead of using the potentially incorrect current CPU load.
- On device wakeup, all cores are forced to wake up

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
	include/linux/cpufreq.h
cleanup
ZenX: Use cpu_load instead of load_since_change, also a code optimization
cpufreq: zenx: allow arbitrary speed / target load mappings

Accept a string of target loads and speeds at which to apply the
target loads, per the documentation update in this patch.  For example,
"85 1000000:90 1700000:99" targets CPU load 85% below speed 1GHz,  90%
at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted.

Attempt to avoid oscillations by evaluating the current speed
weighted by current load against each new choice of speed, choosing a
higher speed if the current load requires a higher speed.

Change-Id: Ie3300206047c84eca5a26b0b63ea512e5207550e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Port this change to ZenX
ZenX: back to load_since_change
cpufreq: ZenX: use a workqueue for hotplugging instead of a realtime thread, ditch the early suspend code for now
cpufreq: zenx: remove load since last speed change

The longer-term load since last speed change isn't terribly useful,
may delay recognition of dropping load, and would need forthcoming
changes to adjust load for changing CPU speeds.  Drop it.

Change-Id: Ic3cbb0542cc3484617031787e03ed9bdd632dec1
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Ported to ZenX
cpufreq: ZenX: perform hotplugging on the same thread as frequency scaling. This should simplify things a bit.
cpufreq: ZenX: re-implement load since speed change for hotplugging
cpufreq: ZenX: fix re-implementation of load_since_change for hotplugging. Don't use it for frequency scaling, though.
cpufreq: ZenX: speed up some of the hotplugging logic (above/below/total load calculations)
cpufreq: ZenX: basically complete rewrite
- Ditch the entire hotplug workqueue
- Add 2 new basic workqueues for add_cpu and remove_cpu. They perform minimum logic to simplify add/remove the CPU that is within their mask
- Remove insert_delay, replace with hot_add_sampling_periods. Now, CPUs will be inserted if average CPU load has been above unplug_load for hot_add_sampling_periods.
- Remove unplug_delay, replace with hot_remove_sampling_periods. Now, CPUs will be removed if average CPU load has been below unplug_load for hot_remove_sampling_periods.
- The logic to determine whether a CPU should be added or removed is all performed on that specific CPUs per-cpu timer set by the governor.
cpufreq: ZenX: don't use cpu_is_offline
'unlikely' branch prediction in the timer is probably going to cost
us several cycles since it will be wrong very often especially
when the device is idle.

cpu_is_offline is defined as unlikely(!cpu_online). Since we expect
auxillary CPUs to be off when the device is idle (likely fairly often),
replace it with !cpu_online and not do any branch prediction.

Not sure the performance improvement this is, but we definitely
don't need the unlikely macro here.
cpufreq: ZenX: remove load_since_change
cpufreq: ZenX: cleanup the timer rearm calls. Fixes an edge case bug where if cpu is offline, and last target_load set is the max, the timer will be destroyed.
Also, rename unplug_load_cpu3 to unplug_load_cpumore and use that value to support up to 8 CPUs.
cpufreq: ZenX: adjust load for changes in speed
Port this change to ZenX

Add notifier for speed transitions.  Keep a count of CPU active
microseconds times current frequency, converted to a percentage relative
to the current frequency when load is evaluated.

Change-Id: I5c27adb11081c50490219784ca57cc46e97fc28c
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: ZenX: specify duration of CPU speed boost pulse
port this change to ZenX

Sysfs attribute boostpulse_duration specifies the duration of boosting CPU
speed in response to bootpulse events.  Duration is specified in usecs,
default 80ms.

Change-Id: Ifd41625574891a44f1787a4e85d1e7b4f2afb52b
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: zenx: add timer slack to limit idle at speed > min
Port this change to ZenX

Always use deferrable timer for load sampling.

Set a non-deferrable timer to an additional slack time to allow prior to
waking up from idle to drop speed when not at minimum speed.  Slack value
-1 avoids wakeups to drop speed.  Default is 80ms.

Remove the governidle module param and its timer management in idle.  For
platforms on which holding speed above mimum in idle costs power, use the
new timer slack to select how long to wait before waking up to drop speed.

Change-Id: I270b3980667e2c70a68e5bff534124b4411dbad5
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: ZenX: rename rw_semaphore mutex to enable_sem like the latest version of that patch
cpufreq: zenx: fix boosting logic
port to ZenX

35a84de cpufreq: zenx: apply above_hispeed_delay to each step above hispeed

caused the speed choice logic to osciallate between boosting and not boosting.
Add back code to ensure speed does not drop below boost frequency while
boosting.