mmc: sdio: fix resume failure

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card
during resume.

(cherry picked from commit 2679307563a616af7ab189706604a245c6a3be92)

Change-Id: I59ff53d8c6d1e151fd8ef50fbd9631d7a904d2d1
CRs-Fixed: 424805
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: prevent possible NULL pointer access

mmc_signal_sdio_irq() should only be called if SDIO interrupt is
received for SDIO card. If mmc_signal_sdio_irq() function is called
when card is not present or for non-SDIO card, it may result into
NULL pointer access (due to uninitialized spin lock access) inside
mmc_signal_sdio_irq() function.

This change fixes the above issue by adding relevant safety checks in
driver.

(cherry picked from commit 94f2f1fee8306fc73e81dcfc01c928eb4749e97a)

Change-Id: I6e42dadb5f0311352b5fd26a574587b6d002cb45
CRs-Fixed: 423795
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: Fix SDCC-BAM, DML reset sequence

Resetting SDCC-BAM after reset of SDCC-DML causes
interface disconnect between SDCC-BAM and SDCC-DML
and lead to hang when SDCC driver initiates data
transfer in BAM mode. Modify the SDCC reset sequence
to reset SDCC-DML after reset of SDCC-BAM.

(cherry picked from commit b745eeb229a476d81ee4177adfe168d3a35bda47)

Change-Id: Ibaed9d84ae004cbda6a0d43a9139659f0ab8c0f1
CRs-Fixed: 423399
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: disable the cache before suspend only after stopping BKOPS

mmc_cache_ctrl was called in runtime suspend before MMC interrupted
BKOPS in case it is still running on the card. This caused the cache
disable to timeout.
Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure
that the card can go into suspend and there is no pending activity.

(cherry picked from commit 67a51386fd99be62e5e68f4bc76ee00c19099cd6)

Change-Id: I2a9a17b4d4b111e976783a40fb9e2c73343ab751
CRs-Fixed: 436805
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit c4dbd80494f7e291f4d851037ec2504f277e7745)
mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

According to UHS-I initialization sequence for SDIO 3.0 cards,
the host must set bit[24] (S18R) of OCR register during OCR
handshake to know whether the SDIO card is capable of doing
1.8V I/O.

(cherry picked from commit 25248b6782085f66787f0b5ea7864bd3dd4e685c)

Change-Id: Iff75f1c52aeff45d80b643107cb5a2c700611ffa
CRs-Fixed: 424685
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: sdio: print correct UHS mode during card detection

When SDIO3.0 card is detected, incorrect bus speed mode
is printed as part of card detection print in kernel logs.

This change fixes it so that user won't be confused by
looking at incorrect card detection message in logs.

(cherry picked from commit 177bf0c4790cbf7e6aa5cfca8235b43c3df2ce6d)

Change-Id: I31e24ea8d1f3a0a62a9be466ac2a58fba14720b9
CRs-Fixed: 424685
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: sdio: fix sdio_reset_comm() to take care of UHS card reset

sdio_reset_comm() function may be invoked by the SDIO card function
driver to execute soft reset of the card but this function currently
fails to reset the UHS SDIO cards.

This change fixes this issue by simply invoking SDIO power restore
function which is capable of resetting both UHS and non-UHS SDIO cards.

(cherry picked from commit 06673c5538c7c961d04b299e1c805c7094ef8c14)

Change-Id: Ia7cf32f0143182a58c22dddd717ad2edf0ce7466
CRs-Fixed: 424685
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: Hard reset controller on errors

For APQ8064 V2 (SDCC version = 0x06000018) doing a soft
reset on errors doesn't reset the state machine that
handles side-band signalling with SPS-BAM fully and can
lead to controller hang for the data transfers after
the reset.

Since there is no register interface to soft reset such
state machine inside the controller, we do hard reset of
the controller in case of errors. SDCC hard reset is
defined as assert and de-assert of asynchronous clock
reset line of the controller.

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

Change-Id: I5a01bb3ed52dc7d4130a3ffe49d955415419ad67
Signed-off-by: Vivek Panwar <vpanwa@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: msm_sdcc: data timeout errors are expected during HS200 tuning

HS200 bus speed mode requires DLL (Delay locked loop) HW block to be
tuned as clock rate (192 MHz) is greater than 100MHz.

While tuning the DLL block by sending CMD21 for different DLL phases,
it is quite possible that few CMD21 may fail with data CRC/timeout
errors as clock phase is not correct but these errors are not really
worth to be printed out as kernel messages. This change doesn't allow
these errors to be printed.

CRs-Fixed: 401743
Change-Id: I2b465a8e1d52458e8663d48791083be7fa4131b2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit fd75b6375585fc3abab50c5829a546dbabf83033)
mmc: msm_sdcc: optimize sampling clock tuning procedure

SDCC-Card tuning sequence comprises of 16 phases. When the
card is detected for the first time the entire tuning
sequence should be implemented to determine the optimum phase
and lock the DLL. However, if the card is transitioning out
of low power mode or when the clock frequency is changed
dynamically, there is no need to carry out tuning sequence
for all 16 phases. It is sufficient to try with the last
successful tuning phase first. This reduces the overhead
involved in executing the entire tuning operation.

In case if the last successful tuning phase has failed,
tuning for all phases needs to be carried out to figure
out optimum phase.

Conflicts:

	drivers/mmc/host/msm_sdcc.h

(cherry picked from commit 306af64158df36453feae8a4c16c60495becca87)

Change-Id: I78ea074a9bdeb5686c96debfcde3490d50beaf09
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: msm_sdcc: perform DLL retuning if clock rate is changed

Using HS200/SDR104 bus speed mode requires DLL (Delay Locked
Loop for sampling clock generation) HW block to be tuned if
clock rate is >100MHz so that both host and card are in sync.

During card initialization, driver uses the tuning command to
search for an optimal sampling point and then programs the
DLL HW with this optimal sampling point.

But if MMC core layer switches the clock frequency to <100MHz
(when HS200/SDR104 timing mode is set) and then increases it
back to >100MHz without calling execute_tuning host ops,
DLL may go to unlocked state. So this change makes sure
that execute_tuning is performed explicitly if clock frequency
switch happens without execute_tuning.

CRs-Fixed: 424685

Conflicts:

	drivers/mmc/host/msm_sdcc.c

(cherry picked from commit 355df54b90e521d55a0a23fd4f157bdfea9def5c)

Change-Id: I19ee19965ca5b6a73a09f9332d34b56602051ebd
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: add support to send auto_cmd19 for CMD53 read operations

SDR104 (supported by SD/SDIO 3.0 spec compliant cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning, SD/SDIO 3.0 specification has added support for tuning commands
(CMD19).

During card initialization, driver uses these tuning commands to search
for optimal sampling point and then configures the DLL HW with this
optimal sampling point.

In addition, our SDCC controller's DLL HW has a mechanism of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.

Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by some amount. SD/SDIO spec does
not mandate the host to send tuning command before every read operations.

CRs-Fixed: 424685
Change-Id: I806317b86f38ed94c6d399fc18caede4f610cf6a
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 67be0a92a4eab75695fc2e4928140127dcf1adda)
mmc: msm_sdcc: don't poll for TX/RX active if haven't waited for prog_done

Few data write commands (like CMD24 (Single Block Write) or ACMD25)
don't have the stop command (CMD12) and in such cases, if the controller
don't support the AUTO_PROG_DONE feature then we may complete the
request having the DAT0 still showing the BUSY status. In such cases,
TX/RX ACTIVE status bits would remain set until the DAT0 status is
changed from busy to ready.

With this change, we are not polling for TX/RX active for above
mentioned cases but reset the DPSM so that we don't end up polling
for TX/RX ACTIVE status for next command (which is generally a status
command).

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

Conflicts:

	drivers/mmc/host/msm_sdcc.c

(cherry picked from commit bfbe58adfe36f2b01333667703d9d8d7a06fa06b)

Change-Id: Ib1f33900a2a1dd09190c92caeb51b421f17c08b3
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: msm_sdcc: don't perform busy wait for CMD13 (status command)

Currently SDCC driver is waiting for the PROG_DONE interrupt after
sending out the CMD13 to card  even if command flags doesn't indicate
so. This may cause the issue in when we try to HPI (High Priority
Interrupt) the ongoing BKOPs (Background Operations). Hence this
change removes the busy wait (PROG_DONE) for CMD13.

Change-Id: I8fb6ab4908bf1c4c5a939413d27eec29cde22f68
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 56fd45187495f27a7f9c3ebe947c1ffc9851fffd)
(cherry picked from commit bcc40276b4effa56feee534e1eb6d7218b03ab5b)
mmc: core: interrupt Background Operations if it takes too long

Currently we have 4 mins timeout for the blocking BKOPs to complete
but we have seen instances where card is surprisingly taking even
longer time to complete background operations.

If card doesn't complete the BKOPs within specified timeout, we
will send the HPI command to interrupt the ongoing BKOPs.

Change-Id: I5df81bdfd9b19bee30a394ee0ff4390b292691d0
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 1b22222ec61924de9b8ac51f08de113548946eb5)
(cherry picked from commit b42dfc56a6e6d26dcf429adee9f9c652b239e1d8)
mmc: core: reduce the maximum timeout for BKOPs

Currently we have 4 mins timeout for the blocking bkops to be completed
but we have seen instances where card is surprisingly taking even more
time to complete their bkops operations. So if we let the card take
more than 4 mins then it would affect the user experience if user tries
to launch some application (or any other user operation resulting in
read from the card) while card is busy doing BKOPs.

User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.

Change-Id: I14355fb79979058f388cd726091752797c316503
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 188b2a8723b4728c7c0c4c445e1aefe6e42895c9)
(cherry picked from commit 3a827d7188b6922d4b57b40992df0f2e84431ba9)
mmc: msm_sdcc: don't print the timeout errors for BKOPs

We have seen instances where card is surprisingly taking lot of time
to complete their bkops operations. And if we let the card take long
time to complete the BKOPs then it would affect the user experience
if user tries to launch some application (or any other user operation
resulting in read from the card) while card is busy doing BKOPs.

User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.

If reduce the timeout to 30 secs then we may see the request timeout
errors during BKOPs so let's silence them out.

Change-Id: I31b11f60d1fae098770aa5797742eaf623b09ac9
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 926a9cb47ebfa40428b49f110135fde9e82f9cbe)
(cherry picked from commit 13f9296570c5af8764f635198f64b7874e921ec2)
mmc: core: Reduce the time to check for BKOPS need on idle

In order to allow the card to perform BKOPS as early as possible without
causing degradation to a flow of requests, we reduce the time of the
BKOPS delayed work to 200ms.
Based on experience, 200ms will allow requests to be performed without
a delay of checking the BKOPS.
This patch also allows the host controller to set any other time if
required.

Change-Id: I1e56bfd0c9471abf4da50befe6d14fe0199129e7
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 70b00220e7564b00e3b0747260fe2c2dbe62f45d)
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 0b59e3e4f87169fb33fde04fda19fe071e5972f1)
mmc: increase BKOPS polling duration before suspend

The timeout for the BKOPS polling is increased in order to allow the
card to complete the BKOPS before going to suspend.
In case we exit due to timeout we need to stop the BKOPS activity
performed by the card.

Change-Id: I39686de0c06a57242f11c8b1c9ae50b33417c088
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit ea1385e6d7542d4e3ad510de94ead00bece7823e)
(cherry picked from commit e8200e78e93950f95469d51aa08fd9f993c96d98)
mmc: Do not perform blocking BKOPS

BKOPS operations can take long time and cause bad user experience and
failure of time critical operations as EFS sync.
In order to prevent the above failures all the levels will be handled only
in idle time BKOPS handling and will allow interrupting the BKOPS when
needed.
In case the card raised an exception with a need for BKOPS, a flag will
be set to indicate MMC to start the BKOPS activity when it becomes idle.

Fixed-CRs: 432027
Change-Id: I5f7b43569c0242f0fea83355f76f286b1ad037bc
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5f8ac3b955e44def61c2238192000ffe5f126714)
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 4f01aaa2b93d4f801ba36bc44cc381d11b1c5a03)