msm: dcvs: remove no longer existing trace events

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
msm: memutils: memcpy, memmove, copy_page optimization
Preload farther to take advantage of the memory bus, and assume
64-byte cache lines.  Unroll some pairs of ldm/stm as well, for
unexplainable reasons.

Future enhancements should include,

- #define for how far to preload, possibly defined separately for
  memcpy, copy_*_user
- Tuning for misaligned buffers
- Tuning for memmove
- Tuning for small buffers
- Understanding mechanism behind ldm/stm unroll causing some gains
  in copy_to_user

BASELINE (msm8960pro):
======================================================================
memcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s
copy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s
copy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s
memmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s
copy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s
copy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s
copy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s

THIS PATCH:
======================================================================
memcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s
copy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s
copy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s
memmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s
copy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s
copy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s
copy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s

Change-Id: I843fe77192d61ce35a81e75d76fc09f0a472e98a
Signed-off-by: Chris Fries <C.Fries@motorola.com>

Conflicts:
	arch/arm/lib/Makefile
	arch/arm/mach-msm/Makefile

Conflicts:
	arch/arm/mach-msm/Makefile
arm: lib: Fix makefile issue
Fix the typo introduced by commit fb7051a.

Change-Id: Ia23c80f903ed431e60e4ba17c9c6d527e6febd87
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/527915
SLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
msm: memutils: memcpy, memmove optimization

1. To fit 8x26 64-bytes cache line size, we change preload steps as 64Bytes.
2. According to tune result, change preload distance as 5 cache lines.
3. According to tune result, re-arrange the ld/str order as back-to-back
   for copy_from_user.

The markable improvement:
	memcpy : 5%
	copy_to_user : 9%
	copy_from_user : 13%
	memmove : 37%

Raw data is as below:

BASELINE:
	memcpy 1000MB at 5MB       : took 1547098 usec, bandwidth 646.646 MB/s
	copy_to_user 1000MB at 5MB : took 1704308 usec, bandwidth 586.586 MB/s
	copy_from_user 1000MB at 5M: took 1777090 usec, bandwidth 562.562 MB/s
	memmove 1000GB at 5MB      : took 1066205 usec, bandwidth 937.937 MB/s
	copy_to_user 1000GB at 4kB : took 1774866 usec, bandwidth 563.563 MB/s
	copy_from_user 1000GB at 4k: took 1797654 usec, bandwidth 556.556 MB/s
	copy_page 1000GB at 4kB    : took 1644606 usec, bandwidth 608.608 MB/s
	memmove 1000GB at 4kB      : took 1236227 usec, bandwidth 808.808 MB/s

THIS PATCH:
	memcpy 1000MB at 5MB       : took 1475835 usec, bandwidth 677.677 MB/s
	copy_to_user 1000MB at 5MB : took 1559060 usec, bandwidth 641.641 MB/s
	copy_from_user 1000MB at 5M: took 1561603 usec, bandwidth 640.640 MB/s
	memmove 1000GB at 5MB      : took 861664 usec, bandwidth 1160.160 MB/s
	copy_to_user 1000GB at 4kB : took 1673501 usec, bandwidth 597.597 MB/s
	copy_from_user 1000GB at 4k: took 1674006 usec, bandwidth 597.597 MB/s
	copy_page 1000GB at 4kB    : took 1691358 usec, bandwidth 591.591 MB/s
	memmove 1000GB at 4kB      : took 882985 usec, bandwidth 1132.132 MB/s

Change-Id: I83bec3b7a9dd9cd88890eaa7ec423363e230a651
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/550383
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
msm: msm_fb: Remove Warnings when required BW exceeds Max Bandwidth.
When required BW exceeds max bandwidth, warnings are printed on the
console which are causing performance degradation. This Patch fixes
the issue.

Change-Id: I769f55dd76a3f28639b848bd5461e2ff3abae3f5
Signed-off-by: Vishnuvardhan Prodduturi <vproddut@codeaurora.org>
(cherry picked from commit 31d3e58)
Reviewed-on: http://gerrit.pcs.mot.com/600169
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Bang Nguyen <bangnguyen@motorola.com>
Reviewed-by: Fred Fettinger <fettinge@motorola.com>
Reviewed-by: Stephen Rossbach <rossbach@motorola.com>
SLTApproved: Stephen Rossbach <rossbach@motorola.com>
(cherry picked from commit ff4d624)
Entropysel fixes
ARM: module: add text.unlikely section to unwind

Add handling for the .text.unlikely unwind sections for cases where
real used code get incorrectly placed by compiler. This solves cases
in which a frequently used function triggers the collectoin of the
current stack trace when using CONFIG_ARM_UNWIND. An example would
be when using CONFIG_SLUB_DEBUG. The constant error printing can
flood the kernel log buffers and cause sluggishness.

Change-Id: I8ca99de24695a46e7fe461b5687c824b900908c8
Signed-off-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/527901
SLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
[LINARO] workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues

Adapted for 3.4 from lsk-v3.10

Workqueues can be performance or power-oriented. Currently, most workqueues are
bound to the CPU they were created on. This gives good performance (due to cache
effects) at the cost of potentially waking up otherwise idle cores (Idle from
scheduler's perspective. Which may or may not be physically idle) just to
process some work. To save power, we can allow the work to be rescheduled on a
core that is already awake.

Workqueues created with the WQ_UNBOUND flag will allow some power savings.
However, we don't change the default behaviour of the system.  To enable
power-saving behaviour, a new config option CONFIG_WQ_POWER_EFFICIENT needs to
be turned on. This option can also be overridden by the
workqueue.power_efficient boot parameter.

tj: Updated config description and comments.  Renamed
    CONFIG_WQ_POWER_EFFICIENT to CONFIG_WQ_POWER_EFFICIENT_DEFAULT.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit cee22a15052faa817e3ec8985a28154d3fabc7aa)
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>

Conflicts:
	kernel/workqueue.c

Conflicts:
	kernel/workqueue.c

Conflicts:
	kernel/workqueue.c
[LINARO] workqueue: Add system wide power_efficient workqueues

Adapted for 3.4 from lsk-v3.10

This patch adds system wide workqueues aligned towards power saving. This is
done by allocating them with WQ_UNBOUND flag if 'wq_power_efficient' is set to
'true'.

tj: updated comments a bit.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 0668106ca3865ba945e155097fb042bf66d364d3)
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
[LINARO] block: queue work on power efficient wq

Adapted for 3.4 from lsk-v3.10

Block layer uses workqueues for multiple purposes. There is no real dependency
of scheduling these on the cpu which scheduled them.

On a idle system, it is observed that and idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most appropriate one.

This patch replaces normal workqueues with power efficient versions.

Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 695588f9454bdbc7c1a2fbb8a6bfdcfba6183348)
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
[LINARO] PHYLIB: queue work on system_power_efficient_wq

Adapted for 3.4 from lsk-v3.10

Phylib uses workqueues for multiple purposes. There is no real dependency of
scheduling these on the cpu which scheduled them.

On a idle system, it is observed that and idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most appropriate one.

This patch replaces system_wq with system_power_efficient_wq for PHYLIB.

Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit bbb47bdeae756f04b896b55b51f230f3eb21f207)
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
[LINARO] ASoC: pcm: Use the power efficient workqueue for delayed powerdown

Adapted for 3.4 from lsk-v3.10

There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
(cherry picked from commit d4e1a73acd4e894f8332f2093bceaef585cfab67)
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
[LINARO] regulator: core: Use the power efficient workqueue for delayed powerdown

There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
(cherry picked from commit 070260f07c7daec311f2466eb9d1df475d5a46f8)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
[LINARO] ASoC: jack: Use power efficient workqueue

The accessory detect debounce work is not performance sensitive so let
the scheduler run it wherever is most efficient rather than in a per CPU
workqueue by using the system power efficient workqueue.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
(cherry picked from commit e6058aaadcd473e5827720dc143af56aabbeecc7)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
ASM: word-at-a-time: make the interfaces truly generic
(Chad Goodman)

Signed-off-by: poondog <markj338@gmail.com>
LIB: use generic strnlen_user and strncpy_from_user functions
(Chad Goodman)

Conflicts:
	arch/arm/Kconfig

Conflicts:
	arch/arm/lib/Makefile

Conflicts:
	arch/arm/Kconfig
ARM: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs
(Chad Goodman)

Signed-off-by: poondog <markj338@gmail.com>
ARM: 7927/1: dcache: select DCACHE_WORD_ACCESS for big-endian CPUs

With commit 11ec50caedb5 ("word-at-a-time: provide generic big-endian
zero_bytemask implementation"), the asm-generic word-at-a-time code now
provides a zero_bytemask implementation, allowing us to make use of
DCACHE_WORD_ACCESS on big-endian CPUs, providing our
load_unaligned_zeropad function is endianness-clean.

This patch reworks the load_unaligned_zeropad fixup code to work for
both big- and little-endian CPUs, then removes the !CPU_BIG_ENDIAN check
when selecting DCACHE_WORD_ACCESS.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Mako: remove LGE KCAL, prepare for MSM KCAL

Conflicts:
	arch/arm/mach-msm/lge/Kconfig