Userspace Voltage Control (thanks faux123)

-Changed CONFIG name to my liking
-Fixed spelling in the Kconfig
cpufreq: Optimize cpufreq_frequency_table_verify()

cpufreq_frequency_table_verify() is rewritten here to make it more logical
and efficient.
 - merge multiple lines for variable declarations together.
 - quit early if any frequency between min/max is found.
 - don't call cpufreq_verify_within_limits() in case any valid freq is
   found as it is of no use.
 - rename the count variable as found and change its type to boolean.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq: Break out early when frequency equals target_freq

Many drivers keep frequencies in frequency table in ascending
or descending order. When governor tries to change to policy->min
or policy->max respectively then the cpufreq_frequency_table_target
could return on first iteration. This will save some iteration cycles.

So, break out early when a frequency in cpufreq_frequency_table
equals to target one.

Testing this during kernel compilation using ondemand governor
with a frequency table in ascending order, the
cpufreq_frequency_table_target returned early on the first
iteration at about 30% of times called.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Add BFQ/SIO/FIOPS/ZEN/VR IO Schedulers
block: row: add magic values.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ALSA: usb-audio: Fix the mixer control range limiting issue

- mixer_ctl_set() function is limiting the volume level
  to particular range. This results in incorrect initial
  volume setting for that device.
- In USB mixer while calculating the dBmin/dBmax values
  resolution factor is hardcoded to 256 which results in
  populating the wrong values for dBmin/dBmax.
- Fix is to use appropriate resolution factor while
  calculating the dBmin/dBmax values.

CRs-Fixed: 515012
Prev-Change-Id: I502355af66f850bb65380c27333c3341fa43a947
Signed-off-by: Deepa Madiregama <dmadireg@codeaurora.org>

Change-Id: I79c14014ad6828a802f6978b796d8a4a91c87e46
ASoC: msm: qdsp6: Fix pop noise seen with touch tone during playback

Issue: When a session is opened for playback of the touch tone and
	routed through the COPP, the PBE and IIR params are being
	reconfigured in the COPP every time a session is open.

Rootcause:Configuring the PBE/IIR in the COPP every time a session
           is open.
Fix: Configuring the PBE and IIR param in the COPP one time a session
      is open

CRs-Fixed: 541722
Prev-Change-Id: If0d1a8c6893a94186e1c6c2a75432d2f4a89f842
Signed-off-by: Satish Kamuju <skamuj@codeaurora.org>

Change-Id: If51d472b554e358f2eada257b7cebb97682683b0
ALSA: pcm: check for integer overflow during multiplication

Channel info data structure is parsed from userspace and if
user does not set the no. of channels correctly, it could lead
to security vulnerability if we don't check for overflow when the
no. of channels is multiplied with pcm bit width. Add a condition
to check for overflow during multiplication.

CRs-fixed: 537818
Prev-Change-Id: Ia3c31406dd8b7627ea704c076643c0348582da28
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>

Change-Id: I577e28017baae43f0ca49141916381c7e791a281
ASoC: msm: qdsp6v2: Copy frame data based on frame length

Copying data based on count will result in copying
uninitialized data to userspace which can potentially
disclose sensitive data. Fix by copying data based on
frame instead.

CRs-Fixed: 552528, 552531
Prev-Change-Id: I307b285ef2aefe00b953cf650582e9ff7e03ceb1
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>

Conflicts:

	sound/soc/msm/qdsp6v2/msm-pcm-voip-v2.c

Change-Id: Ie468d0ccdbd6e253af9bbc7731559856fa302e6e
ALSA: core: Fix crash by avoiding appl_ptr crossing 32-bit boundary

Incase of A2DP usecase using proxy driver, appl_ptr has
boundary value as 0x60000000 frames in sw_params for stereo(2 channels).
When this value crosses 0x40000000, then userspace calculating
appl_ptr at bytes results in crossing 32-bit value 0x100000000,
and points to 0x0 offset which can result in crash or pop.
To avoid above scenario, set the sw_params appl_ptr boundary value
within 0x40000000. Added proper check at sw_params update
to set this value correctly within 32-bit boundary(frames).

Prev-Change-Id: I537a04156699d90549a0a468ae19539ecd552d3b
CRs-Fixed: 483203
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>

Change-Id: Ife1e9debfce7cc62c88ca9587006f0e4e44a7a64
ASoC: msm: qdsp6v2: Fix buffer overflow in voice driver

Userspace registers calibration data with acdb driver
through ioctls. Voice driver registers the calibration
data with CVD by querying acdb data from acdb driver and
copies the calibration data in apr message.

The size of the calibration data can be controlled by userspace
and can result in buffer overflow if the calibration size is
greater than the destination buffer size.
Reject acdb data if the size is greater than the size of
destination buffer.

Prev-Change-Id: I1b495390d67907afc608ed8233bf916777d38e11
CRs-fixed: 548872
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>

Conflicts:

	sound/soc/msm/qdsp6v2/q6voice.c

Change-Id: Ic50d948134a72ab416be1a46ba59e33beb04827d
rwsem-spinlock: Implement writer lock-stealing for better scalability

We (Linux Kernel Performance project) found a regression
introduced by commit:

  5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem

which converted all anon_vma::mutex locks rwsem write locks.

The semantics are the same, but the behavioral difference is
quite huge in some cases. After investigating it we found the
root cause: mutexes support lock stealing while rwsems don't.

Here is the link for the detailed regression report:

  https://lkml.org/lkml/2013/1/29/84

Ingo suggested adding write lock stealing to rwsems:

    "I think we should allow lock-steal between rwsem writers - that
     will not hurt fairness as most rwsem fairness concerns relate to
     reader vs. writer fairness"

And here is the rwsem-spinlock version.

With this patch, we got a double performance increase in one
test box with following aim7 workfile:

    FILESIZE: 1M
    POOLSIZE: 10M
    10 fork_test

 /usr/bin/time output w/o patch                       /usr/bin/time_output with patch
 -- Percent of CPU this job got: 369%                 Percent of CPU this job got: 537%
 Voluntary context switches: 640595016                Voluntary context switches: 157915561

We got a 45% increase in CPU usage and saved about 3/4 voluntary context switches.

Reported-by: LKP project <lkp@linux.intel.com>
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Alex Shi <alex.shi@intel.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Blanchard <anton@samba.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/1359716356-23865-1-git-send-email-yuanhan.liu@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rwsem: Implement writer lock-stealing for better scalability

Commit 5a505085f043 ("mm/rmap: Convert the struct anon_vma::mutex
to an rwsem") changed struct anon_vma::mutex to an rwsem, which
caused aim7 fork_test performance to drop by 50%.

Yuanhan Liu did the following excellent analysis:

    https://lkml.org/lkml/2013/1/29/84

and found that the regression is caused by strict, serialized,
FIFO sequential write-ownership of rwsems. Ingo suggested
implementing opportunistic lock-stealing for the front writer
task in the waitqueue.

Yuanhan Liu implemented lock-stealing for spinlock-rwsems,
which indeed recovered much of the regression - confirming
the analysis that the main factor in the regression was the
FIFO writer-fairness of rwsems.

In this patch we allow lock-stealing to happen when the first
waiter is also writer. With that change in place the
aim7 fork_test performance is fully recovered on my
Intel NHM EP, NHM EX, SNB EP 2S and 4S test-machines.

Reported-by: lkp@linux.intel.com
Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Blanchard <anton@samba.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: paul.gortmaker@windriver.com
Link: https://lkml.org/lkml/2013/1/29/84
Link: http://lkml.kernel.org/r/1360069915-31619-1-git-send-email-alex.shi@intel.com
[ Small stylistic fixes, updated changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
hashtable: introduce a small and naive hashtable

This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
[ Merging this now, so that subsystems can start applying Sasha's
  patches that use this   - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
block,elevator: use new hashtable implementation

Switch elevator to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the elevator.

This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.

This patch depends on d9b482c ("hashtable: introduce a small and naive
hashtable") which was merged in v3.6.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
ASoC: add missing updates from CAF

CAF patch updated board file for 8064 but LGE split the files and the update
was not applied to mako board

Signed-off-by: faux123 <reioux@gmail.com>
Signed-off-by: Seongmin Park <r_data@naver.com>
video: msm_fb: reduce logging level.

Signed-off-by: Francisco Franco <franciscofranco.1990@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/Kconfig
	arch/arm/mach-msm/Makefile

Conflicts:
	arch/arm/lib/Makefile
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/Makefile
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>
Remove '+' symbol from kernel version string

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>