msm_otg: Fix LPM issue on removing Host cable

Device is not entering into LPM on removing Host Cable.
msm_otg_suspend is aborted due to inputs bit is set with
A_BUS_REQ which is check before going ahead and preparing
device for clock OFF and LPM state.

A_BUS_REQ is being set from msm_otg_set_suspend() called
from ehci runtime resume when removing Micro A cable.
Fix side effect of commit 572092fed ("USB: msm_otg: Always
update state machine inputs during bus suspend/resume") by
clearing A_BUS_REQ bit with inputs when removing charger
work from OTG_STATE_B_IDLE.

CRs-Fixed: 444160
Change-Id: I5325d2965ecc754ff54b297047603acda5801aae
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
ASoC: msm: Add support for 4-pole extension cable.

- Add the support to report lineout device when inserted plug
  has high impedance on microphone line.
- This feature is enabled only with gpio headset detection.

Signed-off-by: Ravi Kumar Alamanda <ralama@codeaurora.org>
(cherry picked from commit 07b6bd6a9a1e431a86efa76b14030d882ee7771b)
(cherry picked from commit 39c0e134f67fcab824f1457a256c4fbf2525c347)

Change-Id: I6d4e3f147433ee9c0cc313118b540fee0b90f45f
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: WCD9310: Defer the setup of headphone removal detection.

After the inserted accessory is detected as a valid headphone,
polling is performed on the microphone to correct the accessory
detection in case it was wrongly identified as a headphone.

It was observed that at the end of polling, headphone removal
interrupt was fired, causing headphone playback to stop. Fixed
by deferring the headphone removal setup until either polling is
complete or polling detects a removal

CRs-fixed: 384967
Signed-off-by: Bhalchandra Gajare <gajare@codeaurora.org>
(cherry picked from commit afc86431f330ee51f7980b620bef75935422c764)
(cherry picked from commit f87a8b2658964249917c815719d15abedd03771e)

Change-Id: Ic2c04aa300fc029957c71294e153aef479967b84
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: wcd9310: reduce mbhc button release GPIO debounce time.

Current GPIO debounce time is too long so it delays next button
press detection.  Reduce this debounce time so driver can detect
next button press and release quickly.
Typically mic voltage ramps up within few milliseconds after button
release so 50ms is long enough.

Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(cherry picked from commit db606b0a39452c90e26692c22300c390f5822f29)
(cherry picked from commit 96e92e0a22a0c54f9cfda447d346c1a2dd9f4639)

Change-Id: Ibf0aa4d4c07fab9cd50021cb0e256ee23b320059
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: wcd9310: Turn on EAR DAC and PA at the same time.

Turn on EAR DAC and EAR PA at the same time to avoid pop
at start of playback.

CRs-Fixed: 386288
Signed-off-by: Damir Didjusto <damird@codeaurora.org>
(cherry picked from commit 7c85d71830e1781c113cf1d69234169e8feb31c9)
(cherry picked from commit deb584f6a8788dcda97a9d83038103ebd2576771)

Change-Id: Ib50f6a488fe93595423bae30164073cc25b90076
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: wcd9310: Enhance OCP reporting logic.

CODEC has over current protection(OCP) finite state
machine for both left and right headphone while CODEC
driver tries to delay reporting of OCP event after
CODEC reporting OCP two times. Current CODEC driver
implementation results in unlocking one of headphone
power amplifier when OCP reported on both headphone.
Change the behavior to report OCP event for a give
headphone immediately if OCP already occurs on opposite
headphone.

CRs-fixed: 339620
Signed-off-by: Patrick Lai <plai@codeaurora.org>
(cherry picked from commit c2d833d524c1230c72f2d078b543baba7a8db26f)
(cherry picked from commit 6b8cacf2d5ed669048c3813b56851c10fe5c5af1)

Change-Id: Iea28c8baa1a6372dcb4c0214ec0e74bfc483f563
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: wcd9310: Fix NULL pointer dereference.

If sound card is not yet initialized the platform device's private data
is not set either.  Check if private data is NULL before use it.

CRs-fixed: 400055
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(cherry picked from commit d6e48bd07516ecc683a995ebf8eedf080f14016d)
(cherry picked from commit 87ba6ce49d4f50ad089702135e84ecad5446bfad)

Change-Id: I94e45366d8f316ea8e69def48cc926cdd971f5a6
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
ASoC: wcd9310: Resend edge triggered GPIO IRQ

If MBHC GPIO IRQ for mechanical headset detection asserted while power
management's suspend call chain is being called, wcd9xxx_lock_sleep will
fail to wait for system's resume since power management interface has
to finish suspend in order to resume system.
In this case, interrupt cannot be handled as codec driver cannot
guarantee if underlying bus is awake.
Wake up system and resend the IRQ for this situation.

(cherry picked from commit ecf379cd17b7fe94e6f0df0598a472b6f1828ad5)
(cherry picked from commit bdda99b93915d217150f5484f9c718c905703f1e)
CRs-fixed: 404167
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>

Change-Id: Id5970b359b80e0cd1f701b30c61ade23e0f67b9e
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
ASoC: wcd9310: Update wcd9310 compander configuration

Update the Compander register settings to remain the default
settings after the system bootup and optimize compander
configuration sequence.
CRs-Fixed: 421282

Change-Id: Ib475f3bb84414546b4ead1d3f013dc173317e1b3
Signed-off-by: Kuirong Wang <kuirongw@codeaurora.org>
(cherry picked from commit bc5ac04549d59aaf207a241f1b6a965c83144ae0)

Conflicts:

	include/linux/mfd/wcd9xxx/wcd9310_registers.h
	sound/soc/codecs/wcd9310.c
Signed-off-by: faux123 <reioux@gmail.com>
ASoC: wcd9310: Correct the mixer controls for Compander switches

- Compander1 never gets enabled though the user space sets the
  corresponding mixer control.
- Compander switch kcontrols are configured wrongly as integer
  type with max value as 0.
- Correct kcontrol creation to fix the issue.

CRs-Fixed: 441091

Change-Id: Iad99b44c9226da3bcc1132e61ea989a0543ae56e
Signed-off-by: Ravi Kumar Alamanda <ralama@codeaurora.org>
(cherry picked from commit 4e3f5247bcd098ad1488caa3ecdc3b506e9efbf7)
msm: kgsl: Don't wake up gpu on kgsl_ioctl calls if not necessary

This is Iee3db5401bdad1808a09d104e0daecfc3716cbb4 change ported
manually from the msm-3.4/msm-3.7 branch to the jb_2.5 branch.

The current code wakes up gpu on all kgsl_ioctl() calls that need
to hold device->mutex. However there are some kgsl_ioctl() calls that
don't need that. That fix introduces a bit of info to mark such
functions, and don't wake up gpu calling them to save some power.

Change-Id: I86224d2405c42e3803c7e361c02fe1d02d4cdff1
CRs-Fixed: 438932
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
backported for Mako kernel from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
Sound Control: Sound control for WCD93xx codec

Fully GPL'ed version.

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:
	sound/soc/codecs/Kconfig
	sound/soc/codecs/Makefile

Conflicts:
	sound/soc/codecs/Makefile
	sound/soc/codecs/sound_control_gpl.c
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>
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>
rwsem: make the waiter type an enumeration rather than a bitmask

We are not planning to add some new waiter flags, so we can convert the
waiter type into an enumeration.

Background: David Howells suggested I do this back when I tried adding
a new waiter type for unfair readers. However, I believe the cleanup
applies regardless of that use case.

Signed-off-by: Michel Lespinasse <walken@google.com>
rwsem: shorter spinlocked section in rwsem_down_failed_common()

This change reduces the size of the spinlocked and TASK_UNINTERRUPTIBLE
sections in rwsem_down_failed_common():

- We only need the sem->wait_lock to insert ourselves on the wait_list;
  the waiter node can be prepared outside of the wait_lock.

- The task state only needs to be set to TASK_UNINTERRUPTIBLE immediately
  before checking if we actually need to sleep; it doesn't need to protect
  the entire function.

Signed-off-by: Michel Lespinasse <walken@google.com>
rwsem: move rwsem_down_failed_common code into rwsem_down_{read,write}_failed

Remove the rwsem_down_failed_common function and replace it with two
identical copies of its code in rwsem_down_{read,write}_failed.
This is because we want to make different optimizations in
rwsem_down_{read,write}_failed; we are adding this pure-duplication
step as a separate commit in order to make it easier to check the
following steps.

Signed-off-by: Michel Lespinasse <walken@google.com>
rwsem: simplify rwsem_down_read_failed

When trying to acquire a read lock, the RWSEM_ACTIVE_READ_BIAS adjustment
doesn't cause other readers to block, so we never have to worry about waking
them back after canceling this adjustment in rwsem_down_read_failed().

We also never want to steal the lock in rwsem_down_read_failed(), so we
don't have to grab the wait_lock either.

Signed-off-by: Michel Lespinasse <walken@google.com>
rwsem: simplify rwsem_down_write_failed

When waking writers, we never grant them the lock - instead, they have
to acquire it themselves when they run, and remove themselves from the
wait_list when they succeed.

As a result, we can do a few simplifications in rwsem_down_write_failed():

- We don't need to check for !waiter.task since __rwsem_do_wake() doesn't
  remove writers from the wait_list

- There is no point releaseing the wait_lock before entering the wait loop,
  as we will need to reacquire it immediately. We can change the loop so
  that the lock is always held at the start of each loop iteration.

- We don't need to get a reference on the task structure, since the task
  is responsible for removing itself from the wait_list. There is no risk,
  like in the rwsem_down_read_failed() case, that a task would wake up and
  exit (thus destroying its task structure) while __rwsem_do_wake() is
  still running - wait_lock protects against that.

Signed-off-by: Michel Lespinasse <walken@google.com>
rwsem: more agressive lock stealing in rwsem_down_write_failed

Some small code simplifications can be achieved by doing more agressive
lock stealing:

- When rwsem_down_write_failed() notices that there are no active locks
  (and thus no thread to wake us if we decided to sleep), it used to wake
  the first queued process. However, stealing the lock is also sufficient
  to deal with this case, so we don't need this check anymore.

- In try_get_writer_sem(), we can steal the lock even when the first waiter
  is a reader. This is correct because the code path that wakes readers is
  protected by the wait_lock. As to the performance effects of this change,
  they are expected to be minimal: readers are still granted the lock
  (rather than having to acquire it themselves) when they reach the front
  of the wait queue, so we have essentially the same behavior as in
  rwsem-spinlock.

Signed-off-by: Michel Lespinasse <walken@google.com>