Revert "Fastcharge"

This reverts commit 4907d67705cf087c23c36d00640b7fdccffaa77e.
Initial overclock to 1836

Conflicts:
	arch/arm/mach-msm/acpuclock-8960.c
Fix overclock, enable all steppings

Conflicts:
	arch/arm/mach-msm/acpuclock-8960.c
block/sioplus-iosched.c: add sioplus scheduler - credit boype

Conflicts:
	block/Kconfig.iosched
	block/Makefile
include/linux/elevator.h: Add elevator_queue_empty_fn to support sioplus iosched
Add wheatley governor

Conflicts:
	arch/arm/configs/cyanogen_apexq_defconfig
	drivers/cpufreq/Makefile
	include/linux/cpufreq.h
msm: Remove all references to CONFIG_ANDROID_PMEM

CONFIG_ANDROID_PMEM is completely deprecated. Remove all
references to it.

Change-Id: Ie1f2b08094fffdf308025d43bf4c8c164e52340b
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
Change-Id: I42953704c7a32382fb8529304499088665dbbd33
msm: iommu: re-use existing buffers for `extra' mappings

There is a bug on some hardware that requires us to overmap Iommu
mappings by 2x. Currently, we set aside a dummy buffer onto which we
map all of these dummy mappings. In general, for large mappings it's
nice to use the more efficient iommu_map_range instead of calling
iommu_map repeatedly. However, with our current approach in
msm_iommu_map_extra we can't use iommu_map_range for page_sizes larger
than the dummy buffer. To avoid wasting memory by increasing the size
of the dummy buffer, we can simply remap on top of the the buffer
being mapped in the first place. Since the second mapping should never
be used (besides by the buggy hardware) this should not be a problem.

Re-use existing buffers for all `extra' mappings. Essentially, map the
same physical address range twice. To be extra safe, make the second
mapping read-only.

Change-Id: I35462ad50de8da1f2befa3e3f0895925535cdc98
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
video: msm: Increase video encoding output buffer size

When bistream buffer size is half of YUV buffer size, video core
may be put into a bad state where output buffers are not returned
back to user space. Increasing the output buffer size solves the issue.

Change-Id: Ie30ec084a764717526c74fc3f89d2684c7020f09
Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>