New governor "Nightmare". Modified KEY_HOMEPAGE in mach-u1.c for JB-Sammy.
mali: update gpu dvfs table voltages as soon as the driver is initialized

this commit is originally from AndreiLux's s3 kernel which also requires you to change the init sequence of the asv part.
However, in siyahkernel, gpu is initialized after the rom type is detected hence that commit is not applied.
+ updated build-script ...
+ "cpufreq: interactive: don't handle transition notification if not enabled" - https://github.com/android/kernel_common/commit/8e2dfe161140c53bb79a8b2a87a38ff6e2e8a8a9
nightmare and ZenX are HOT PLUG govs they have there ways. allow them.
Removed ZenX and nightmage GOVS from allowed hot plug control.

ZenX cant boot second CPU! one one active. if allowed to use hotplug
nightmare stuck kernel if allowed to use hotplug.

without hotplug control, all OK. and working good.
+ "Remove trace events from ZenX" - https://github.com/AndroidDeveloperAlliance/ZenKernel_TUNA/commit/7083f9f40a0dfc78967374ed0bc992601c12bf26
+ "Pegasusq tweaks primarily suggested by mnagy1987" - https://github.com/AndroidDeveloperAlliance/ZenKernel_TUNA/commit/47630c49926caf57d6ebcd32b0f90b93d8c4162b
+ sync with "cpufreq: ZenX: add ZenX governor v2.1" - https://github.com/AndroidDeveloperAlliance/ZenKernel_TUNA/commit/665cafe6952dc7c32050504f330c008d36a0048c#diff-3
cpufreq: ZenX: fix rearm_if_notmax calling, causing incidental timer stopping.
usb: gadget: accessory: Fix section mismatch (again)

create_bulk_endpoints should not be __init since it is called when
accessory is enabled.

Change-Id: Iac6e9f29d53c93760e926efd8e7603432632acb4
Signed-off-by: Todd Poynor <toddpoynor@google.com>
android: logger: enforce GID and CAP check on log flush

Restrict log flushing to those in the logs group, or
anyone with CAP_SYSLOG.

Change-Id: I5d6977d1c0d60ffe8487771cc195789e5db95454
Signed-off-by: Charndeep Grewal <csgrewa@tycho.ncsc.mil>
sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).
finish applying the LOAD_FREQ (4*HZ+61) avoids loadavg Moire patch from http://ripke.com/loadavg/moire

Conflicts:
	include/linux/sched.h
timers: Avoid finding cpu for migration of running timers in __mod_timer()

Currently we don't support migration of currently running timers. Current code
flow in __mod_timer() is:
- Find a cpu where we should migrate the timer
- Check if timer is currently running
- If yes, don't migrate.

In this process, the first step is a unnecessary activiy, if the timer is
currently running. This patch tries to avoid it in such cases.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
backported from Linux 3.5+ by faux123
block: Adding ROW scheduling algorithm

This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin manner with a different slice for each queue.
READ request queues get bigger dispatch quantum than the write requests.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

+ ...
row: Adding support for reinsert already dispatched req

Add support for reinserting already dispatched request back to the
schedulers internal data structures.
The request will be reinserted back to the queue (head) it was
dispatched from as if it was never dispatched.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
row: Add support for urgent request handling

This patch add support for handling urgent requests.
ROW queue can be marked as "urgent". If an urgent queue was
un-served in a previous dispatch cycle and a request was added
to it - it will trigger issuing urgent request to the device driver.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: Add support for reinsert a dispatched req

Add support for reinserting a dispatched request back to the
scheduler's internal data structures.
This capability is used by the device driver when it chooses to
interrupt the current request transmission and execute another (more
urgent) pending request. For example: interrupting long write in order
to handle pending read. The device driver re-inserts the
remaining write request back to the scheduler, to be rescheduled
for transmission later on.

Add API for verifying whether the current scheduler
supports reinserting requests mechanism. If reinsert mechanism isn't
supported by the scheduler, this code path will never be activated.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: Add support for reinsert a dispatched req

This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may decide to
interrupt the currently running low priority request to serve the new
urgent request. By doing so READ latency is greatly reduced in read&write
collision scenarios.

Note that if the current scheduler doesn't implement the urgent request
mechanism, this code path is never activated.

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>