ASoC: msm: FENS Support for VOIP calls

Add support FENS for Voip calls. Support is added by adding new
Mixer control

CRs-Fixed: 460878
Change-Id: I4c05155ac1de7b8da5b5e1ae24776c3e98b353f2
Signed-off-by: Sidipotu Ashok <sashok@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.

Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
sparc64: Fix argument sign extension for compat_sys_futex().

[ Upstream commit aa3449ee9c87d9b7660dd1493248abcc57769e31 ]

Only the second argument, 'op', is signed.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Make itc_sync_lock raw

[ Upstream commit 49b6c01f4c1de3b5e5427ac5aba80f9f6d27837a ]

One more place where we must not be able
to be preempted or to be interrupted in RT.

Always actually disable interrupts during
synchronization cycle.

Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Handle 32-bit tasks properly in compute_effective_address().

[ Upstream commit d037d16372bbe4d580342bebbb8826821ad9edf0 ]

If we have a 32-bit task we must chop off the top 32-bits of the
64-bit value just as the cpu would.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Fix top-level fault handling bugs.

[ Upstream commit 70ffc6ebaead783ac8dafb1e87df0039bb043596 ]

Make get_user_insn() able to cope with huge PMDs.

Next, make do_fault_siginfo() more robust when get_user_insn() can't
actually fetch the instruction.  In particular, use the MMU announced
fault address when that happens, instead of calling
compute_effective_address() and computing garbage.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses.

[ Upstream commit e5c460f46ae7ee94831cb55cb980f942aa9e5a85 ]

This was found using Dave Jone's trinity tool.

When a user process which is 32-bit performs a load or a store, the
cpu chops off the top 32-bits of the effective address before
translating it.

This is because we run 32-bit tasks with the PSTATE_AM (address
masking) bit set.

We can't run the kernel with that bit set, so when the kernel accesses
userspace no address masking occurs.

Since a 32-bit process will have no mappings in that region we will
properly fault, so we don't try to handle this using access_ok(),
which can safely just be a NOP on sparc64.

Real faults from 32-bit processes should never generate such addresses
so a bug check was added long ago, and it barks in the logs if this
happens.

But it also barks when a kernel user access causes this condition, and
that _can_ happen.  For example, if a pointer passed into a system call
is "0xfffffffc" and the kernel access 4 bytes offset from that pointer.

Just handle such faults normally via the exception entries.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.

[ Upstream commit b18eb2d779240631a098626cb6841ee2dd34fda0 ]

Access to the TSB hash tables during TLB misses requires that there be
an atomic 128-bit quad load available so that we fetch a matching TAG
and DATA field at the same time.

On cpus prior to UltraSPARC-III only virtual address based quad loads
are available.  UltraSPARC-III and later provide physical address
based variants which are easier to use.

When we only have virtual address based quad loads available this
means that we have to lock the TSB into the TLB at a fixed virtual
address on each cpu when it runs that process.  We can't just access
the PAGE_OFFSET based aliased mapping of these TSBs because we cannot
take a recursive TLB miss inside of the TLB miss handler without
risking running out of hardware trap levels (some trap combinations
can be deep, such as those generated by register window spill and fill
traps).

Without huge pages it's working perfectly fine, but when the huge TSB
got added another chunk of fixed virtual address space was not
allocated for this second TSB mapping.

So we were mapping both the 8K and 4MB TSBs to the same exact virtual
address, causing multiple TLB matches which gives undefined behavior.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Add membar to Niagara2 memcpy code.

[ Upstream commit 5aa4ecfd0ddb1e6dcd1c886e6c49677550f581aa ]

This is the prevent previous stores from overlapping the block stores
done by the memcpy loop.

Based upon a glibc patch by Jose E. Marchesi

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
sparc64: Do not insert non-valid PTEs into the TSB hash table.

[ Upstream commit 18f38132528c3e603c66ea464727b29e9bbcb91b ]

The assumption was that update_mmu_cache() (and the equivalent for PMDs) would
only be called when the PTE being installed will be accessible by the user.

This is not true for code paths originating from remove_migration_pte().

There are dire consequences for placing a non-valid PTE into the TSB.  The TLB
miss frramework assumes thatwhen a TSB entry matches we can just load it into
the TLB and return from the TLB miss trap.

So if a non-valid PTE is in there, we will deadlock taking the TLB miss over
and over, never satisfying the miss.

Just exit early from update_mmu_cache() and friends in this situation.

Based upon a report and patch from Christopher Alexander Tobias Schulze.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
staging: android: lowmemorykiller: select a new task to kill

Under certain circumstances, a process may take time to handle a SIGKILL.
When lowmemkiller is called again shortly after, it would pick the same
process to kill over and over, so that we cann't get free memory for long time.

Solution is to check fatal_signal_pending() on the selected task, and if it's
already pending, select a new task to kill.

Cherry-pick 5e3358093351e5d48e21250e31896b855542f22c
Reviewed-on: http://gerrit.pcs.mot.com/479831

Change-Id: I53445114451ffaba293f3c7174fb0b01ed0d34b6
Signed-off-by: Tianshui Shi <kfp634@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/505410
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
(cherry picked from commit da093001caf06ed2296b4f79c84cc48ce713eac6)
staging: android: persistent_ram: allow printing to old buf

This change adds interface which can be used to print to old
persistent ram. We'll be able to add some useful annotations
to last_kmsg.

Change-Id: I4b6aaaaf3285d31b2e1ac0244d7ba01399bb7fa6
Signed-off-by: Yuanyuan Zhong <a6510c@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/504784
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
(cherry picked from commit 616fadfe57503a765d3034fa33dab0445d3f1967)
staging: android: binder:add ioctl BINDER_GET_PEER_PID

Add new ioctl BINDER_GET_PEER_PID to let user-space app to
inquire peer's pid of current transaction.

This is ported from

 *(CR): Scorpion_mini:UT: System Server Watchdog
  Reviewed-on: http://gerrit.pcs.mot.com/466351

Change-Id: Idfffd7e3bb9a81e52068ba599c25e605b612675e
Signed-off-by: Yi-wei Zhao <gbjc64@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/506479
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
(cherry picked from commit 40b6938286a96c80f27ad9ccbe013b44599dd9ad)
staging: android: persistent_ram: free temporary buffer

When there is no valid old persistent_ram buffer, we need to free
the temporary buffers which are supposed to be merged into old
persistent_ram buffer.

Change-Id: I2fc06dbb78a98f0734fc866fa7ef92a140578bb7
Signed-off-by: Yuanyuan Zhong <a6510c@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/508951
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
(cherry picked from commit f540c1b3bf666ee1a5f288e76e2774293b3ed5e9)
staging: android: fdleak_dbg: Debugging FD leak

File Descriptor leak checking will be disabled in "user" build,
but enabled in "userdebug" and "eng" builds. When enabled, if
a process tries to create a big file descriptor (i.e. >= 512),
or to inject a big file descriptor into a remote process via
Binder IPC, the culprit thread's backtrace will be dumped in
Android "main" log.

If the culprit process' executable file is /system/bin/app_process,
the process must be an Android process with one SignalCatcher thread.
Then kernel sends SIGUSR1 to the process and waits <= 100ms until
the process' SignalCatcher thread finishes dumping the Java and
native backtrace of the culprit thread.

If the culprit process' executable file is not /system/bin/app_process,
kernel considers the culprit thread as a non-Java pthread, and launches
"/system/bin/helsmon start log_backtrace -p <culprit_thread_tid> --big_fd_created <fd>"
, which requests "/system/bin/helsmond" to dump the culprit thread's
native backtrace

Use http://zch68maindev.ap.mot.com/stabdev/tools/tombstones.php
to parse the native backtrace

Change-Id: I1a6d04007b9e901c66b22e5c655753473b828c19
Signed-off-by: GAO LIANG-TAO <w20048@motorola.com>
Change-Id: I0d8ef47b679a7162c2c0c4da7438e888913dc7a1
Reviewed-on: http://gerrit.pcs.mot.com/512022
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit fef661186e4f33758ecf2b71088903c48b01b626)
staging: android: binder: Debugging FD leak

Signed-off-by: GAO LIANG-TAO <w20048@motorola.com>
(cherry picked from commit cdae4b7951c96c28030daf3d801dcc322989c946)

Change-Id: Ic876b03f82cc8d400c9bd5901001ff0852afef84
staging: android: logger: Add kernel console log driver

1. Fix the known drawback from /proc/kmsg kernel log source.
2. Provide the unified timestamps for main, system, radio and kernel offline logs.

Signed-off-by: Dong-Dong Yang <gdb746@motorola.com>
(cherry picked from commit 5e01ed94e63c3ef2fb93861fb1c2847b8d2173f4)

Change-Id: If7c8de6b6dbdbf0deafe583f577854b3afb19fea
staging: android: fdleak_dbg: Use MIN_BIG_FD as bottom line

Signed-off-by: GAO LIANG-TAO <w20048@motorola.com>
Change-Id: Ifb337feb4667e7194d029389f413e63357fb74b6
Reviewed-on: http://gerrit.pcs.mot.com/513326
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit 866789473ec06db9524ef3befa5f232d8425fa7d)
staging: android: ram_console: add current boot info at the end of last_kmsg

Add boot command line and powerup reason info to the end of
last_kmsg to provide the current boot status and parameters
for debugging analysis purpose.

Change-Id: I4dab5ce649ed1608e4b8d997b15b71368476e095
Signed-off-by: Dong-Dong Yang <gdb746@motorola.com>
Change-Id: I28b0c6dacb479b08d737c291cfe9adeabf2b6413
Reviewed-on: http://gerrit.pcs.mot.com/514124
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Zhi-Ming Yuan <a14194@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit f3894c43b035e28b8b026d372029b5b982b4087b)
Swap thread id and process id

BZ: 31375

Change-Id: I80c25de5fbb0d7196f5e620bbc9f597882558a1e
Signed-off-by: Christophe Guerard <christophe.guerard@intel.com>
Reviewed-on: http://android.intel.com:8080/43418
Reviewed-by: Kanigeri, Hari K <hari.k.kanigeri@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
Reviewed-on: http://gerrit.pcs.mot.com/519858
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Patrick Auchter <wpa722@motorola.com>
Reviewed-by: Dong-Dong Yang <gdb746@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
(cherry picked from commit 255562a593bed902ee99c0fc40b9c92cc228a1d8)