rwsem: steal writing sem for better performance
Commit 5a50508 changes to rwsem from mutex, caused aim7 fork_test
performance to dropped 50%. Yuanhan liu did an analysis, found it was
caused by strict sequential writing. Ingo suggest stealing sem writing from
front task in wait queue. https://lkml.org/lkml/2013/1/29/84

So does this patch.
In this patch, I just allow write stealing to happen when the first waiter
is also writer. The performance fully is now fully recovered.

Reported-by: lkp@linux.intel.com
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Alex Shi <alex.shi@intel.com>
ASoc: msm: Add support for multiple inputs to kcontrol

Adds the macro SOC_SINGLE_MULTI_EXT which allows the user
to pass the number of integer inputs accepted by the control.

Change-Id: I75009672568d1e0979ecd577031e72bd87f310d2
Signed-off-by: Ben Romberger <bromberg@codeaurora.org>
ASoC: core: Fix the suspend/resume failure

The suspend/resume schedule work fails because of the
uninsantiated sound card. The fix is to skip the
schedule work for the uninsantiated sound card.

CRs-fixed: 339411
Signed-off-by: Kuirong Wang <kuirongw@codeaurora.org>
(cherry picked from commit 5ab054fb0655bb0ab6820a18e931fabf69053ea9)

Change-Id: Icf303ffef9d7019c936510dc676ba83eeec84f1c
Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
mmc: block: claim host in mmc_blk_set_blksize() only if required

Following is the sequence during system resume (dpm_resume()):
1. SDCC driver resume gets called which does nothing as it will
   find the device as runtime suspended.
2. As part of dpm_resume() itself, mmc_bus_resume() is called which
   results in this call flow:
	mmc_bus_resume -> mmc_blk_resume -> mmc_blk_set_blksize ->
	mmc_claim_host -> mmc_host_enable -> host_ops->enable ->
	SDCC driver runtime resume.

We really don't want to do runtime resume of SDCC as part of
dpm_resume() othewise it will increase the latency of overall
system resume path.

For sector addressed cards (card size > 2GB), default blocksize is
512 bytes which means setting block length by sending
CMD16 (SET_BLOCKLEN) is not required for such cards. But
mmc_blk_set_blksize() first claims host and then check if card requires
CMD16 or not. mmc_claim_host() will cause runtime resume of SDCC device.
So it's better to first check if card requires CMD16 or not for setting
block length to 512 and then claim the host only if it's required.

CRs-fixed: 344459
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit c63f0e528184082408f75d690602a4e2013a49b1)

Change-Id: Ib6e20a796bd7c832026bd8b78d8a049e84374d02
Signed-off-by: Gopal G Goberu <ggober@codeaurora.org>
mmc: core: capture performance numbers only when asked

Currently performance numbers are captured for each SDCC
transfers unconditionally which may add the overhead and
could reduce the SDCC read/write throughput numbers.

This change adds additional control for enabling/disabling the
capturing of performance numbers at runtime. We already have sysfs
entry named "perf" for msm sdcc devices. Currently setting this
entry to 0 clears the performance statistics. But now we are
changing the definition of this entry as mentioned below:

Disable performance capturing and clear the performance statistics:
	"echo 0 > /sys/devices/platform/msm_sdcc.<n>/perf"

Enable performance capturing:
	"echo 1 > /sys/devices/platform/msm_sdcc.<n>/perf"

CRs-fixed: 345170
Change-Id: I36b040cae7aba7a1a11814e69ab6cd344da8c75c
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: Fix deadlock in mmc_suspend_host and mmc_rescan

SDCC runtime suspend can race with mmc_rescan causing deadlock.
The call flow would be this:
1) When runtime suspend is triggered:
	msmsdcc_runtime_suspend()
		-> mmc_suspend_host()
			-> mmc_flush_scheduled_work()
2) mmc_flush_schedule_work() waits for mmc_rescan() work
to be completed if it is already in runqueue.
3) When mmc_rescan() is scheduled to run:
	mmc_claim_host()
		-> msmsdcc_enable()
			->pm_runtime_get_sync()
4) pm_runtime_get_sync() waits for runtime_suspend to complete,
and hence cause two threads to wait upon each other.

Fix this deadlock by aborting runtime suspend when mmc_rescan
is scheduled.

CRs-Fixed: 326610
Change-Id: I4ca88651f80f5a1bfccb6e0c07e3ea83fadcdc57
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Export mmc_set_ios so that host drivers can use it

mmc_set_ios() is used by host drivers during suspend/resume
routines in indirect way i.e., by calling host->ops->set_ios().
But now with MMC_CLKGATE enabled, mmc_set_ios() also updates
host->clk_gated flag. So export this API so that host controller
drivers can use it.

CRs-Fixed: 346559
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit f0410bc6dcacabf599f999f4779091f5cd2c55dc)

Change-Id: Ib7ad7588c1ba4ae5da3ceaaade18caf7c4bdecd1
Signed-off-by: Srivalli Oguri <oguri@codeaurora.org>
mmc: msm_sdcc: fix gray code values

DLL (Delay Locked Loop) HW block inside SDCC4 controller
can take 16 different phases (0 to 15). Value of these phases
should be written in gray code format in HW register.

But gray code values used in driver are wrong and differs
from standard definition of gray codes. This patch fixes the
gray code values to be compliant with standard definition of
gray codes.

CRs-fixed: 334493
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit fac0a0910b15a90ff9e41ee85ac644467b1b6f17)

Change-Id: I98cb3b06b3d1b665b42a02599898ef86cbc1e485
Signed-off-by: Srivalli Oguri <oguri@codeaurora.org>
msm: msm_sdcc: fix data/cmd CRC errors during SDR104 mode operation

SDR104 mode requires DLL (Delay locked loop) HW block to be tuned
as clock rate is greater than 100MHz. But we observed multiple CMD
CRC errors while erasing the SD card and DATA/CMD timeout errors
while writing/reading on to SD card if it's running in SDR104 bus
speed mode (SD clock rate @192MHz).

DLL has a mechansim of data tracking (CDR) which can be enabled
during RX transaction so the host will not lose the sampling point.
CMD19 (tuning pattern command) can be sent automatically before
any RX transaction for helping the CDR to track after the correct
sampling point.

But if this data tracking is kept enabled during TX transactions then
it may cause the DATA/CMD CRC errors during TX transactions. So this
patch ensures that data tracking is only enabled during RX transactions
and remains disabled for TX transactions.

In addition to this change, it is found that DLL valid phase windows
may be cyclic so this patch also ensures that 2 different valid phase
windows are treated as single valid window if it's cyclic.

(cherry picked from commit 8b6ee57c9fa744de72c630b22e10e7abb4a670b0)

Change-Id: I9fc39268893b3d77feb676438e598e3659165c95
CRs-fixed: 334000
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: reset IO_PAD_PWR_SWITCH when non UHS-I SD card is inserted

SDCC driver sets the IO_PAD_PWR_SWITCH bit to 1 to indicate
SDCC controller that IO pad voltage level needs to be switched
from 3.3v to 1.8v when initializing UHS-I (SD3.0 compliant) cards.
But if UHS-I card is inserted first and then removed after that
and now if we insert the non UHS-I card then there is a possibility
that IO_PAD_PWR_SWITCH bit may still remain set to 1.

This change resets the IO_PAD_PWR_SWITCH bit to 0 if voltage
switch from 3.3v to 1.8v is not required.

CRs-fixed: 337145
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 00083572d8bfbba92df374310993ed7555e90dab)

Change-Id: I4a7a50e7fbf59b4d1339560748c9942dd90ae7c0
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
mmc: msm_sdcc: fix possible buffer overflow

If "total_phases" argument of find_most_appropriate_phase()
function have value greater than 16, it may cause the
out bound access for arrays used within this function.

So this patch validates the value of "total_phases" to
avoid buffer overflow.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 3418704d2e3df7a78961ae7a2a7a74fd3977ef39)

Change-Id: Idea1b50fefa0af1971879c4c3e0e48651da8c273
Signed-off-by: Yen-Pin Hsiao <yphsiao@codeaurora.org>
mmc: msm_sdcc: Advertise erase capability

SD/MMC card erase functionality is available in core
layer. Enable MMC_CAP_ERASE capability from host side
so that users can use erase, trim, secure erase, secure trim
operations based on the card capability.

CRs-Fixed: 346552

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 31a45ce6faa0f2e150eed6777cbb3ae8f2f08219)

Change-Id: Ia243a1b9b5a9a49eb4e3db1882004a2b300bf831
Signed-off-by: Gopal G Goberu <ggober@codeaurora.org>
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>