msm_sdcc: remove 5-second mdelay on command timeout

Signed-off-by: Iliyan Malchev <malchev@google.com>
mmc: sdhci: add auto command error interrupt support

The auto command error interrupt is not enabled now. Hence,
if there occurs a timeout when auto-cmd is in progress,
no data timeout interrupt would occur and the driver would
only timeout after the software timer expires.

This patch enables the auto command error interrupt and lets the
higher layers know of such an error, if any.

CRs-Fixed: 515513
Change-Id: I69880a72ece7730645dcfe699d58271d60cab33d
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: sdhci: fix issue with auto cmd err detection

As per specification, auto cmd error status register is valid only
when auto cmd error bit is set in Error interrupt status register.

Change-Id: Id1013e1705d8efdba0171dcad14f783607d38ef3
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: ChangGyun Kim <cg.kim@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
mmc: sdhci: ignore the hardware timeout when requested

Few card commands can be interrupted (using HPI command) if it takes
longer time to complete so in such case its acceptable to get the
timeout errors hence ignore them when MMC core layer request for it.

Change-Id: I347a2171e21746643e5f39eb927394d55cbca46e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: expose HPI capability to SWITCH commands

Some of the time consuming operations such as BKOPS, SANITIZE, CACHE
flush/off use the SWITCH command (CMD6) but as these operations don't
have card specification defined timeout for completion, we may see
timeout errors if card doesn't complete the operation within the SW
defined timeout. If SW defined timeout is hit, above operations are
considered to be failed and no real recovery mechanism is implemented
after timeout.

Most of the above operations (BKOPS/SANITIZE/CACHE flush/off) can be
interrupted by sending the HPI (High Priority Interrupt) command to card
if they taking longer than expected. This change adds the base support
which will these operations to be HPIed after timeout.

Change-Id: I5b4bfd9fed30f5e4ad57cd4f06c85ae5c5ba169d
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: msm_sdcc: change the bkops_busy flag check to ignore_timeout

MMC core layer have made the "bkops_busy" flag in the mmc_command
structure absolute, use "ignore_timeout" instead.

Change-Id: Ib3c01dafce3f099895cadf5cf29cc370a6a15fc2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: handle flush requests timeout

According to the eMMC 4.5 spec "Flushing a large amount of cached data may
take very unpredictably long time". Therefore the timeout for FLUSH should
be increased to prevent timeouts.

In case the timeout occurs HPI issued.

Change-Id: Ib4f7e43d32d14f5d4e112057c7427f4b97957518
CRs-Fixed: 500874
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: core: hpi in TRAN state error handling

There could be a race condition in the stop transmission request.
1. Urgent read request comes in.
2. Stop the ongoing write request by calling stop_request MMC host op.
3. Send the stop command (CMD12) to move the card from the receive state
   to programming state.
4. Send the status command (CMD13) to know if the card is in programming
   state or not. If yes, then go to step.5 or else go to step.6.
5. Send the HPI command to bring the card out of programming state.
6. Now send the urgent read request.

In above sequence in step.4, we check if the card is in programming or
not and if it is then we go ahead and send the HPI in step.5 but what if
after step.4 is completed and before the step.5, card moves out of the
programming state so in that case HPI command would timeout as we are
sending it in the wrong state. In that case no command response (by eMMC
protocol) causes mmc_send_hpi_cmd to fail (with -ETIMEOUT error).  In
case the card indeed in TRAN state, no error is reported.

Change-Id: Ia6f81f6cc4ec933f2e8423029f7236401aea04df
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: sdhci-msm: Ignore AHB bus transfer stop request

The latest SDHCI controller core v3.1.0 can handle reset in middle of an
ongoing transfer without the need to stop AHB bus transaction
separately.

Change-Id: I34d2359dd2b22696a70cc146652811cb866a1d3c
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
mmc: core: dont send PON during suspend

During suspend, eMMC VCC can be turned off. So instead of sending
a power off notification, send a sleep command. According to the
eMMC 4.5 specification, this is the only time where its clearly
mentioned that the VCC regulator can be turned OFF.

This has been clarified in eMMC 5.0 specification and this applies
even if PON with sleep is not sent to the card.

Change-Id: I6c424bed3158132af7f9c2a2a701af7369fd5ec7
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: core: Enable multiple urgent requests notification

At the moment if the block layer issues an URGENT request notification
before receiving a complete on the URGENT request currently handled by
the device driver - the system crashes with a BUG_ON().
This change enables multiple block layer urgent request notification to
be handled by MMC layer by removing single notification enforcement.

CRs-fixed: 517724
Change-Id: Idfa410d0c2286146f8d58a38b5abd6886036317c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
mmc: sdhci: Add a mechanism to disable HPI

Certain cards might cause a timeout when used with HPI mode
due to card specific issues. Provide a mechanism where HPI
mode can be turned OFF to workaround such issues.

Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
mmc: sdhci-msm: Enable controller power save feature

Enable power save feature within controller by setting bit 1
in vendor specific register (0x10C). This allows controller to
disable SD clock when bus is idle to save power.

https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/drivers/mmc?id=efad7a79d65e9fe73e28efd96392a6e48ab26529

Bug: 10796623
Change-Id: I916a5a414adb3f21dc3a75f3f86c3a81d6956dc8
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
mmc: sdhci-msm: Fix issue with power save bit enablement

The power save bit is currently enabled based on the clock
rate (clk_rate > 400KHz) within struct sdhci_msm_host. But this
clk_rate is updated with the latest value down in this function
sdhci_msm_set_clock(). So during runtime/system resume when the
card is still in initialization phase, the power save bit is
getting enabled when sdhci_msm_set_clock() is called for the
first time based on the previous rate which is wrong.

https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/drivers/mmc/host/sdhci-msm.c?h=msm-3.4&id=5c85f7950219cbcc3a9360a6731ac104b7d2efd7

Bug: 10796623
Change-Id: I05dc8a4a760f658935de3831aaf8dd3b2b996466
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
mmc: block: fix a bug of error handling in MMC driver

Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.

This patch includes the following functionality:
  1. To enable error checking for the response of CMD12 and CMD13
     in write command sequence
  2. To retry write sequence when a generic error occurs

Messages are added for v2 to show what occurs.

cherry-picked it from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc?id=c8760069627ad3b0dbbea170f0c4c58b16e18d3d

Change-Id: I2bc5224a83b931a11e4664c449050323c34cdec5
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
mmc: sdio: Update the buffer copy to include the last char

During the copy the last character was getting truncated.
Update the buffer copy to include all the characters.

CRs-Fixed: 499579
Change-Id: I8e1df1d1f2294e85068aebcc876bef701e088b07
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: msm_sdcc: Fix null pointer dereference in msmsdcc_pio_irq()

In a case where, the data transfer is scheduled in PIO mode, the write
data pend feature is enabled and the command corresponding to the data
transfer is timedout, it can happen that the failure recovery mechanism
clears the internal data transfer structure but not the PIO IRQ mask.
Since the msmsdcc_irq() and msmsdcc_pio_irq() are shared IRQ handlers,
the data structures free'd in command timeout interrupt routine might
be accessed in the msmsdcc_pio_irq() causing NULL pointer dereference.
Fix this by clearing PIO IRQ mask before stopping the data transfer.

CRs-Fixed: 498700
Change-Id: If597eed5da1707b8cbfb2c9c305719bf21d0eec5
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
bcmdhd: Reset the hang flag after the notifications are sent

... and put back the pseudo-tuning code in mmc to avoid erroring out
on reinit