arm/Makefile + Makefile: Add -pipe
Support CONFIG_CMDLINE_EXTEND config option

http://permalink.gmane.org/gmane.linux.kernel/1248085
ZenX: Add ZenX governor, zeneractive v2

ZenX: Fix some merge errors

ZenX: Use cpu_load instead of load_since_change, also a code optimization

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

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.

cpufreq: ZenX: use longer-term CPU load for hotplugging. Also adjust default unplug_load_cpu1 and reduce hot_remove_nr_periods, defaults are still probably a bit too conservative

cpufreq: ZenX: remove debug statement

cpufreq: ZenX: group all hotplugging logic together (workqueue queing and determination logic). Also move it below all of the load computation and frequency scaling logic.

cpufreq: ZenX: add early suspend notifier to change some governor tunables when the device is suspended/awoken.

cpufreq: ZenX: port change ID Ife77cf9fe099e8fd8543224cbf148c6722c2ffb0

cpufreq: ZenX: revert target_loads stuff for now

cpufreq: ZenX: re-work the hotplugging logic to take the average average load after hot_remove/add_nr_sample_periods and compare it to unplug_load to determine whether or not to remove that CPU.
The way it was done before was fine, but resetting the counters if average load is above/below unplug load is a bit unfair in such a short sampling window. So it's probably better to take a long-term sample (similar to hotplug gov).

cpufreq: ZenX: remove unncessary call_hp_add/remove variables. Also, reset all timers when making a hotplug decision, that way we won't end up in a hotplug situation potentially the very next cycle.

cpufreq: ZenX: Fix improper reset of add/remove counters for load/periods

cpufreq: ZenX: initialize tunables at compile time

Revert "cpufreq: ZenX: interactive: revert target_loads stuff for now"

cpufreq: ZenX: remove un-necessary target_set_time and target_set_time_in_idle

cpufreq: ZenX: add missing semicolon/fix syntax error