ASoC: msm: stereo call recording support

Patch that allows for call recording in
stereo (left channel: TX; right channel:
RX). Tested on Nexus 5 (MSM8974). Likely
works on other recent MSM chipsets as
well.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
slim_msm: Handle ADSP SSR gracefully for apps-owned data channels

Usually the data channels are owned by codec, or by ADSP itself. If
apps itself is involved in data-transfer on the channels, make sure
the BAM pipes, or the port-registers in question are not accessed
while ADSP is restarting.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ngd_slim: Ignore pm_runtime_get error when runtime-pm is not enabled

Controller power-up uses different code-path when runtime-pm is not
enabled.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
slim_msm: support non-blocking writes from slimbus MSM controller

Provide non-blocking write support so that clients can queue multiple
writes, or larger transfers without performance implications.
TX buffer is created and descriptors out of this buffer
are submitted to HW to transmit data.
Descriptor is returned to 'available' pool of TX buffer when HW
interrupt for transmission status is recieved.

Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
block: Switch from BFQ-v7r5 for 3.4.0 to BFQ-v7r6 for 3.4.0

. IMPROVEMENT: Introduced a new mechanism that helps get the job done
  more quickly for services and applications that create or reactivate
  many parallel I/O-bound processes. Examples are systemd at boot, or
  commands such as git grep.
. CODE IMPROVEMENTS: Small code cleanups and improvements.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
power: make sync on suspend optional

On embedded devices with built-in batteries, it is not so
important to sync the file systems before suspend.  The chance
of losing power during suspend are no greater than they are
when the system is awake.  The sync operations can greatly
increase suspend latency when the system has accrued many dirty
pages and/or the target storage devices are not particularly
fast.

This commit adds a kernel config option to allow file system
sync in the suspend and earlysuspend paths to be disabled.  It is
enabled by default.  It also exposes two command line options to
control this feature: suspendsync and earlysuspendsync.

Signed-off-by: Russ Knize <Russ.Knize@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/614512
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Igor Kovalenko <igork@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
[neo: Disabled by default.]
Signed-off-by: Pranav Vashi <neobuddy89@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

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

arm: lib: Fix makefile bug

When HAS_MACH_MEMUTILS is defined, two version of memcpy.S would
be built at the same time, fix the issue here.

Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.mot.com/629464
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@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

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: memutils: 8974: memcpy, memmove optimization

According to tune result, change preload distance to 10
cache lines for 8974.
And considering bkk-b is sharing code for 8974, 8226, 8x16,
we seperate the code for 8974 specially.

The markable improvement:
    memcpy : 67%
    copy_to_user : 37%
    copy_from_user : 37%
    memmove : 70%

Raw data is as below:

BEFORE:
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s
	copy_to_user 1000MB at 5MB : took 681202 usec, bandwidth 1467.467 MB/s
	copy_from_user 1000MB at 5M: took 682052 usec, bandwidth 1466.466 MB/s
	memmove 1000GB at 5MB      : took 763133 usec, bandwidth 1310.310 MB/s
	copy_to_user 1000GB at 4kB : took 714487 usec, bandwidth 1399.399 MB/s
	copy_from_user 1000GB at 4k: took 699861 usec, bandwidth 1428.428 MB/s
	copy_page 1000GB at 4kB    : took 634857 usec, bandwidth 1575.575 MB/s
	memmove 1000GB at 4kB      : took 791389 usec, bandwidth 1263.263 MB/s
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s

AFTER:
	memcpy 1000MB at 5MB       : took 395178 usec, bandwidth 2530.530 MB/s
	copy_to_user 1000MB at 5MB : took 497667 usec, bandwidth 2009.009 MB/s
	copy_from_user 1000MB at 5M: took 496832 usec, bandwidth 2012.012 MB/s
	memmove 1000GB at 5MB      : took 449217 usec, bandwidth 2226.226 MB/s
	copy_to_user 1000GB at 4kB : took 489006 usec, bandwidth 2044.044 MB/s
	copy_from_user 1000GB at 4k: took 483982 usec, bandwidth 2066.066 MB/s
	copy_page 1000GB at 4kB    : took 377170 usec, bandwidth 2651.651 MB/s
	memmove 1000GB at 4kB      : took 483015 usec, bandwidth 2070.070 MB/s

Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.mot.com/634422
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
SLTApproved: Christopher Fries <c.fries@motorola.com>
Reviewed-by: John Zafiris <johnz@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
sound: Export effects header to userspace

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: qdsp6v2: Clear ION handle after freeing

Once ion memory is freed ion handle should be set to
NULL to avoid double free or any unintended access.
This change clears the ION handle after freeing up
the memory.

Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoc: msm: qdsp6: Add ultra low latency playback support

Using ULL further reduces continuous latency when
compared to the current low latency path.
This is achieved by having no post-processing in
the DSP along with smaller buffer sizes

Signed-off-by: Aleksander Holynski <aholynsk@codeaurora.org>
Signed-off-by: Krishnankutty Kolathappilly <kkolat@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Fix playback failure on device switch during ULL playback

When a device switch happens for ultra low latency playback, we are
opening a regular playback COPP. ULL stream is routed to a non ULL
COPP. ULL stream can be only routed to a ULL COPP. This results in
playback failures. The fix is to use the perf mode flag as a
part of front end instead of back end dai.

Signed-off-by: Krishnankutty Kolathappilly <kkolat@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: qdsp6v2: Set ADM sample rate to 48Khz for ULL

ULL copp can only operate at sample rate of 48Khz. BT SCO back end
sets sample rate is 8Khz. ADM open for  ULL fails when backend is
BT SCO. Set the sample rate to 48Khz when adm is opened for a ULL
device session.

Signed-off-by: Krishnankutty Kolathappilly <kkolat@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: qdsp6v2: Set ADM channel to max supported for ULL

ULL copp can only operate currently for 2 Channels.
ADM open for ULL fails for channel greater than 2 channels
Set the channel to max supported
when adm is opened for a ULL device session.

Signed-off-by: Vimal Puthanveed <vimalp@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Add support for ASM loopback

Add ASM loopback driver. When audio path wants to use filters in DSP,
it will do a loopback in ASM.  The new ASM loopback driver enables
the loopback.

Signed-off-by: Damir Didjusto <damird@codeaurora.org>
Signed-off-by: Vimal Puthanveed <vimalp@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: qdsp6v2: Add support of ULL and LL

Add support for Low latency pcm and Ultra low latency pcm in
legacy pcm driver. A flag, part of device tree is used to
differentiate low latency and ultra low latency.
Only one ULL stream can be be connected to one ULL COPP.
LL stream can be connected to LL or regular COPP.

Signed-off-by: Krishnankutty Kolathappilly <kkolat@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Defer probe during sound card registration

ASoC framework returns probe defer when all the
components of the sound card are not registered.
MSM audio machine driver has to handle the probe
defer gracefully.

Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: q6: check upper bounds when copy ac3 params

Although AC3 maximum param size is fixed, better check upper bounds
when copy user data. It might cause overflow, possibly cause memory
corruption.

Signed-off-by: Fred Oh <fred@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Route low latency frontend to in-call music backend

Add routing controls to support routing of low latency stream
to in-call music delivery backend.

Signed-off-by: Narsinga Rao Chella <nrchella@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Change acdb_mmap size variable to unsigned

The acdb_mmap fuction does a size calculation but
stores the result in an int which makes negitive
numbers possible. Changing the variable to unsigned
ensures that the size used is never out of bounds.

Signed-off-by: Ben Romberger <bromberg@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: Add playback support for AC3/EC3 in compress driver

- Dolby DS1 supports both AC3 and EC3 playback in compress
  path. Add code in offload compress driver to support
  playback of AC3/EC3 formats.

Signed-off-by: Mingming Yin <mingming@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>