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>
Revert "mmc: sdio: optimized SDIO IRQ handling for single irq"

This reverts commit 06e8935febe687e2a561707d4c7ca4245d261dbe.
With the optimization, the sdio_irq_thread() sends a spurious
interrupt notification to the registered function handler during
ksdioirq thread start up. The function handler may or may not
handle this interrupt gracefully. The correct way to inform
about interrupt is to check CCCR_INTx register for pending
interrupts before calling function driver's irq handler
which is broken with this optimization, hence the revert.

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

Change-Id: I7ea674b7ac343491c4965b5007d4d48696cbfa43
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: Power down slots after reboot

Some reboot methods (eg. adb reboot) may not power
down SDCC slots. This can result in cards being
in unexpected states after reboot. Explicitly reset
slot voltage regulator on reboot.

CRs-Fixed: 341840
Change-Id: I8cdb52bc58e34900378af468794760653f3babad
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
mmc: msm_sdcc: reset wait_for_auto_prog_done flag in case of an error

"wait_for_auto_prog_done" flag is set when CMD53, single block write
(CMD24) or pre-defined (prefixed with CMD23) multi block write
(CMD25) need to be sent to card. This flag tells the
msmsdcc_start_data() to set the AUTO_PROG_DONE bit in MCI_DATA_CTL
register. If AUTO_PROG_DONE bit is set, SDCC controller will raise
the PROG_DONE at the end of above mentioned write transfers
(command + data) and "wait_for_auto_prog_done" gets cleared at
the end of transfer.

But if we get the error during the command transfer phase itself,
there is a chance that "wait_for_auto_prog_done" remains set which
means it remains sticky during next SDCC transfer request as well.
And if next data transfer is data read operation, having this
"wait_for_auto_prog_done" flag set will not allow the transfer to
end which may cause SDCC driver to raise request timeout.

Following is one such error condition:
<6>[  667.001892] mmc1: CMD6: Request timeout
<6>[  667.004700] mmc1: SDCC PWR is ON
<6>[  667.007904] mmc1: SDCC clks are ON, MCLK rate=400000
<6>[  667.012848] mmc1: SDCC irq is enabled
<6>[  667.067633] mmc1: SPS mode: busy=0
<6>[  667.071020] mmc1: xfer_size=64, data_xfered=64, xfer_remain=0
<6>[  667.076758] mmc1: got_dataend=1, prog_enable=0,
			wait_for_auto_prog_done=1, got_auto_prog_done=0

This patch ensures that "wait_for_auto_prog_done" gets cleared even when
error is seen during command transfer phase itself.

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

Change-Id: I951f6d6bd3bb518a3c047d9c7cf1f3e0fd0dda39
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@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>
mmc: msm_sdcc: vote for msm bus bandwidth

If there is no voting for the system fabric clock, it may run at the
minimum clock speed. If system fabric is running at lower speed (than
what is needed by SDCC workload), SDCC read & write throughput numbers may be
degraded.

This patch adds the msm bus voting for bandwidth required by SDCC driver
based on card clock speed and bus width.

Adapted to shooter_u by Johnnyslt

CRs-Fixed: 355327
Change-Id: I7fbcbe22beb09408f8460f815a6f7d34105e21cb
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Darescu Ionut <johnny@esi.ro>
mmc: msm_sdcc: clean up sysfs attributes

Currently SDCC driver is using couple of sysfs attributes but
data for these attributes is global so shared by all the
SDCC host controllers but for example, one sysfs attribute named
"polling" is required only for few slots. But as all attribute data
is global, all the slots are getting the "polling" attribute even
if it's not required for few slots.

This change adds attribute data into the host controller (msmsdcc_host)
structure so each host controller can add the required attributes
based on their need.

Change-Id: I22616062e67d57af49f932a98735c8f95bc741d4
CRs-fixed: 368937
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>