Fastcharge for HTC One m8

Signed-off-by: flar2 <asegaert@gmail.com>
Disable HTC /system write protection

Signed-off-by: flar2 <asegaert@gmail.com>
Overclocking and undervolting options

Signed-off-by: flar2 <asegaert@gmail.com>
Show pvs in sysfs

Signed-off-by: flar2 <asegaert@gmail.com>
msm: cpufreq: Add API to allow limiting of min and max cpu frequencies

CPUFreq provides scaling sysfs nodes to set min and max frequencies, but
there are times when the operating range has to be controlled
irrespective of the scaling limits, to ensure the thermal stability of
the device.

The API allows kernel thermal safeguards to pitch in and limit the
frequencies.

Change-Id: I3dc7496747792e6223695131f1644dd87054b025
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
Signed-off-by: flar2 <asegaert@gmail.com>
Overclocking: fix and add more steps

Signed-off-by: flar2 <asegaert@gmail.com>
sysfs interface from GPE source

Signed-off-by: flar2 <asegaert@gmail.com>
Bump overclocking voltages a bit

Signed-off-by: flar2 <asegaert@gmail.com>
Add gboost

Signed-off-by: flar2 <asegaert@gmail.com>
msm: clock-krait-8974: User voltage control for msm-cpufreq device

Signed-off-by: flar2 <asegaert@gmail.com>
Adjust min and max voltage limits

Signed-off-by: flar2 <asegaert@gmail.com>
Change auto undervolting to use min freq only and adjust oc voltages

Signed-off-by: flar2 <asegaert@gmail.com>
PM: devfreq: Use high priority workqueue

It does not make sense to run kgsl on high and devfreq on regular
priority.

Signed-off-by: flar2 <asegaert@gmail.com>
Disable magnetic cover event

Signed-off-by: flar2 <asegaert@gmail.com>
Set up underclocking and overclocking

Signed-off-by: flar2 <asegaert@gmail.com>
mm: slub: Default slub_max_order to 0

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations up to order-3 by default and falls back to
lower allocations if they fail. While care is taken that the caller
and kswapd take no unusual steps in response to this, there are
further consequences like shrinkers who have to free more objects to
release any memory. There is anecdotal evidence that significant time
is being spent looping in shrinkers with insufficient progress being
made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.

SLUB is now the default allocator and some bug reports have been
pinned down to SLUB using high orders during operations like
copying large amounts of data. SLUBs use of high-orders benefits
applications that are sized to memory appropriately but this does not
necessarily apply to large file servers or desktops.  This patch
causes SLUB to use order-0 pages like SLAB does by default.
There is further evidence that this keeps kswapd's usage lower
(https://lkml.org/lkml/2011/5/10/383).

Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: flar2 <asegaert@gmail.com>