eMMC's may have a hardware reset line. This patch provides a host controller operation to implement hardware reset and a function to reset and reinitialize the card. Also, for MMC, the reset is always performed before initialization. The host must set the new host capability MMC_CAP_HW_RESET to enable hardware reset. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org> (cherry picked from commit b2499518b5ad7e28bb3ed348fd3f370eeb1e36c0)
On a tegra3 platform with Hynix eMMC we can observe that sometimes we receive a command timeout after a transfer complete interrupt on a multiple block read request. Here is the output using MMC_DEBUG and ftrace. When it works: tegra_sdhci_set_clock: tegra_sdhci_set_clock mmc0 0 enabled=1 tegra_sdhci_set_clock: tegra_sdhci_set_clock mmc0 52000000 enabled=0 __mmc_start_req: mmc0: starting CMD18 arg 00a73044 flags 000000b5 __mmc_start_req: mmc0: blksz 512 blocks 2 flags 00000200 tsac 150 ms nsac 1000 __mmc_start_req: mmc0: CMD12 arg 00000000 flags 0000049d sdhci_irq: sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 sdhci_finish_command: sdhci_finish_command:1075 sdhci_irq: sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000002 sdhci_tasklet_finish: sdhci_tasklet_finish:2064 When we have the error: tegra_sdhci_set_clock: tegra_sdhci_set_clock mmc0 0 enabled=1 tegra_sdhci_set_clock: tegra_sdhci_set_clock mmc0 52000000 enabled=0 __mmc_start_req: mmc0: starting CMD18 arg 00a63d12 flags 000000b5 __mmc_start_req: mmc0: blksz 512 blocks 2 flags 00000200 tsac 150 ms nsac 1000 __mmc_start_req: mmc0: CMD12 arg 00000000 flags 0000049d sdhci_irq: sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 sdhci_finish_command: sdhci_finish_command:1075 sdhci_irq: sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00018000 ------NOW THE REQUEST BLOCK UNTIL TIMEOUT------ We can see that when it works the multiple read blocks command stopped by the CMD12 receive two interrupts. The first is the Transfer complete interrupt (SDHCI_INT_RESPONSE) and just after the Block Gap Event interrupt (SDHCI_INT_DATA_END). In this case the command is finished and the data is finished too. In the bad case instead of receiving SDHCI_INT_DATA_END we receive a command timeout error (SDHCI_INT_TIMEOUT) but command was already finished by the SDHCI_INT_RESPONSE so not more command is waiting and the driver wait until the timeout timer end because this case is not managed. Signed-off-by: Nicolas Serafini <nicolas.serafini@sensefly.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Dominik Sliwa <dominik.sliwa@toradex.com>
This fixes the following eMMC suspend/resume issue as seen on Colibri T30 1GB IT V1.1A: [ 75.479664] mmcblk0: error -110 transferring data, sector 287240, nr 2, cmd response 0x900, card status 0xc00 [ 75.580923] end_request: I/O error, dev mmcblk0, sector 287240 [ 75.586782] Buffer I/O error on device mmcblk0p2, logical block 123140 [ 75.593313] lost page write due to I/O error on mmcblk0p2 (fixes an issue probably caused by a merge conflict introduced by commit 7f7b042a978edfc6c7d1e14ec9c6ec01ffcc284b) Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Dominik Sliwa <dominik.sliwa@toradex.com>
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. As some of the other features like BKOPs/Cache/Sanitize are dependent on HPI feature, those features would also get disabled if HPI is disabled. Change-Id: I6a638ce089cbd977122e47aecb721bc3f0adf7b0 Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Fix ported from the following Android MSM kernel commit: https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?id=84af3731019921a28d595dbf6cbf00539706a42c
It is fully legal for a controller to start handling busy-end interrupt before it has signaled that the command has completed. So make sure we do things in the proper order, Or it results that command interrupt is ignored so it can cause unexpected operations. This is founded at some toshiba emmc with the bellow warning. "mmc0: Got command interrupt 0x00000001 even though no command operation was in progress." This issue has been also reported by Youssef TRIKI: It is not specific to Toshiba devices, and happens with eMMC devices as well as SD card which support Auto-CMD12 rather than CMD23. Also, similar patch is submitted by: Gwendal Grignou <gwendal@chromium.org> Changes since v1: Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git and Tested if issue is fixed again. Signed-off-by: Hankyung Yu <hankyung.yu@lge.com> Signed-off-by: Chanho Min <chanho.min@lge.com> Tested-by: Youssef TRIKI <youssef.triki@st.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> (cherry picked from commit e99783a45220a2c5f5a598e0e81213ecf2dbcf2f)
When we wait for busy after sending a command, if there is a timeout, we got SDHCI_INT_DATA_TIMEOUT flags. Before this commit we got the message : "Got data interrupt 0x00100000 even though no data operation was in progress." and we need to wait 10s that sdhci_timeout_timer expires. Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> (cherry picked from commit c5abd5e8998e20c2e82999670a03f26f1437d744)
We don't need to change the SDHCI_SDIO_IRQ_ENABLED flag when we're merely receiving an interrupt - IRQ handling thread in the MMC core will either re-enable or disable the interrupt via the enable_sdio_irq callback, which will update this status appropriately. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net> (cherry picked from commit ef104333a234f66cd13fd16632086a21b90fced6)
sdhci interrupt handling is a mess; there is a lot of code doing very
similar things. Let's clean this up a bit:
1. set's clear down cmd, data and bus power interrupts in one go - we're
always going to handle these.
2. use a do { } while () loop for looping while there are pending
interrupts.
3. group clearing of bits in intmask into one place.
This results in the code becoming simpler and easier to read.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit 41005003bcaf4ecfc80e02af01247f2670269816)
When using MSI it is possible that a new MSI is sent while an earlier MSI is currently handled. In this case SDHCI_INT_STATUS only contains SDHCI_INT_RESPONSE and the ISR would not be called again. But at the end of the ISR SDHCI_INT_DATA_END is now also pending which would be ignored. Fix this by rereading the interrupt flags in the ISR until no interrupt we care is pending. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org> (cherry picked from commit 6379b2375a0c5a6ad437616a4018e6b8fd95e97c)
Ths patch allows runtime PM for sdhci-pci, runtime suspending after inactivity of 50ms and ensuring runtime resume before SDHC registers are accessed. During runtime suspend, interrupts are masked. The host controller state is restored at runtime resume. For Medfield, the host controller's card detect mechanism is supplanted by an always-on GPIO which provides for card detect wake-up. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org> (cherry picked from commit 66fd8ad5100b5003046aa744a4f12fa31bb831f9)