linux/drivers/mmc, branch v4.9

mmc: dw_mmc: fix the error handling for dma operation

2016-11-21T10:08:28Z

When dma->start is failed,then it has to fall back to PIO mode for current transfer. But Host controller was already set to bits relevant to DMA operation. If needs to use the PIO mode, Host controller has to stop the DMA operation. (It's more stable than now.) When it occurred error, it's not running any request. Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support") Reported-by: Marek Szyprowski Signed-off-by: Jaehoon Chung Reviewed-by: Shawn Lin Cc: # v4.3+ Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson

mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

2016-11-18T13:41:47Z

Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()") the ESDHC driver is broken: mmc0: Card stuck in programming state! __mmc_switch mmc0: error -110 whilst initialising MMC card Since this commit __mmc_switch() uses ->card_busy(), which is sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the PRESENT_STATE register, specifically the DAT0 signal level bit. But the ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is required to make the driver work again. Signed-off-by: Michael Walle Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()") Acked-by: Yangbo Lu Acked-by: Adrian Hunter Cc: # v4.8+ Signed-off-by: Ulf Hansson

mmc: mxs: Initialize the spinlock prior to using it

2016-11-07T12:30:08Z

An interrupt may occur right after devm_request_irq() is called and prior to the spinlock initialization, leading to a kernel oops, as the interrupt handler uses the spinlock. In order to prevent this problem, move the spinlock initialization prior to requesting the interrupts. Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by: Fabio Estevam Reviewed-by: Marek Vasut Signed-off-by: Ulf Hansson

mmc: mmc: Use 500ms as the default generic CMD6 timeout

2016-11-07T12:29:52Z

In the eMMC 4.51 version of the spec, an EXT_CSD field called GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum time it may need to move out from its busy state, when a CMD6 command has been sent. In cases when the card is compliant to versions < 4.51 of the eMMC spec, obviously the core needs to use a fall-back value for this timeout, which currently is set to 10 minutes. This value is completely in the wrong range and importantly in some cases it causes a card initialization to take more than 10 minute to complete. Earlier this scenario was avoided as the mmc core used CMD13 to poll the card, to find out when it stopped signaling busy. Commit 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") changed this behavior. Instead of reverting that commit, which would cause other issues, let's instead start by picking a simple solution for the problem, by using a 500ms default generic CMD6 timeout. The reason for using exactly 500ms, comes from observations that shows it's quite common for cards to specify 250ms. 500ms is two times that value so likely it should be enough for most cards. Cc: # v4.8+ Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Signed-off-by: Ulf Hansson Tested-by: Stephen Boyd Tested-by: Linus Walleij

mmc: mmc_test: Fix "Commands during non-blocking write" tests

2016-11-07T12:28:38Z

mmc_test_check_result_async() requires that struct mmc_async_req is contained within struct mmc_test_async_req. Fix the "Commands during non-blocking write" tests so that is the case. Fixes: 4bbb9aac9a9a ("mmc: mmc_test: Add tests for sending commands during transfer") Signed-off-by: Adrian Hunter Tested-by: Ritesh Harjani Signed-off-by: Ulf Hansson

mmc: sdhci: Fix missing enhanced strobe setting during runtime resume

2016-11-07T12:26:43Z

Restore enhanced strobe setting during runtime resume. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson

mmc: sdhci: Reset cmd and data circuits after tuning failure

2016-11-07T12:26:43Z

To prevent subsequent commands failing, ensure the cmd and data circuits are reset after a tuning timeout. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson

mmc: sdhci: Fix unexpected data interrupt handling

2016-11-07T12:26:42Z

In the busy response case (i.e. !host->data), an unexpected data interrupt would result in clearing the data command as though it had completed but without informing the upper layers and thus resulting in a hang. Fix by only clearing the data command for data interrupts that are expected. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson

mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer

2016-11-07T12:26:42Z

CMD line reset during an ongoing data transfer can cause the data transfer to hang. Fix by delaying the reset until the data transfer is finished. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson

mmc: dw_mmc: add the "reset" as name of reset controller

2016-11-07T07:53:46Z

Add the "reset" as name of reset controller. This is for preventing the wrong operation. Even if some SoC has reset controller, doesn't define "resets" in device-tree. Then it might be waiting for reset controller and it should be stuck. Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host controller") Signed-off-by: Jaehoon Chung Acked-by: John Stultz Signed-off-by: Ulf Hansson