- 25 Jul, 2016 40 commits
-
-
Adrian Hunter authored
In order to support commands during data transfer, there will have to be up to two active requests (mrqs) at a time, instead of just one. That means ensuring that all requests get errored out in the cases of card or driver removal. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Several pointers are used to identify when interrupts are expected. Namely, host->cmd, host->data_cmd and host->data. Ensure those are cleared when a request finishes. That tidies the case when a request is errored out before normal processing has completed, ensuring any interrupts that occur subsequently are not acted upon. Signed-off-by:
-
Adrian Hunter authored
SDHCI recovers from errors by resetting the cmd and data circuits. Until that is done, there very well might be more interrupts, so ignore them in that case. Signed-off-by:
-
Adrian Hunter authored
Factor out sdhci_needs_reset() so it can be reused. Signed-off-by:
-
Adrian Hunter authored
In order to support commands during data transfer, there will have to be up to two active requests (mrqs) at a time, instead of just one. That means the driver must identify which one to finish. Prepare for that by factoring out sdhci_finish_mrq(). Signed-off-by:
-
Adrian Hunter authored
In order to support commands during data transfer, it will be possible that host->data is not NULL when preparing a new request. Move a warning that assumes otherwise. Signed-off-by:
-
Adrian Hunter authored
In order to support commands during data transfer, there will have to be up to two active requests (mrqs) at a time, instead of just one. That means host->mrq will not be able to be used. In several places, host->mrq is used when instead the mrq can be determined from the cmd or data pointers. Reduce the use of host->mrq by doing that. Signed-off-by:
-
Adrian Hunter authored
Now that there is host->data_cmd to record the command for which a data interrupt is expected, it is possible to determine whether a command with busy signaling has completed without an extra flag. So host->busy_handle is not needed. Remove it. Signed-off-by:
-
Adrian Hunter authored
In order to support commands during data transfer, there must be a distinction between the command that is using the command line (and for which a command interrupt is expected) and the command that is using the data lines (for which a data interrupt is expected). There is host->cmd for the command line, but there is only host->data for the data lines, which is a different structure, does not represent the command in use, and is anyway NULL in the case of commands that use the data lines for busy signalling instead of data transfer. Introduce host->data_cmd to record what command is using the data lines, and use that instead of host->cmd when referring to the data command. Signed-off-by:
-
Adrian Hunter authored
sdhci_finish_command() is going to set host->cmd to NULL. Simplify the code by using a local variable to hold host->cmd and set host->cmd to NULL at the start. Signed-off-by:
-
Adrian Hunter authored
BUG is never the right thing for SDHCI to do. Get rid of BUG_ON in cases it will oops anyway if the pointer is NULL, or if the condition is logically impossible. Signed-off-by:
-
Adrian Hunter authored
In order to support commands during data transfer, command and data handling needs to be untangled. That means sdhci_finish_cmd() must not be called from the data IRQ handler. It is being called because of busy signal handling, which is treating the command as not finished until the busy signal is released. Instead, move busy signal handling from sdhci_cmd_irq() into sdhci_finish_cmd(). Then the data IRQ handler does not need to call sdhci_finish_cmd() and can instead finish the request. What this means in practice for a command with busy signaling, is that the command response is read from the host controller when the command complete interrupt is received, thus freeing up the command circuit for other commands. Signed-off-by:
-
Adrian Hunter authored
At the successful conclusion of sdhci_pci_probe(), if runtime pm was allowed, the device would be runtime suspended. That wastes a lot of time during initialization. Instead leave the device active until the mmc core scans for a card. Signed-off-by:
-
Adrian Hunter authored
Add sdhci_read_caps() and __sdhci_read_caps() to make it easier for drivers to fix the version and capabilities registers. Pedantically, the SDHCI specification states that the capabilities registers are valid when the host controller resets the Software Reset For All bit. That requirement has always been satisfied by performing a reset at the start of initialization, and consequently that is now part of the new functions. Although the SDHCI_QUIRK_MISSING_CAPS quirk has not yet been removed, drivers that want to provide their own caps can now use these functions instead of that quirk. Signed-off-by:
-
Adrian Hunter authored
In preparation for adding a function to read the capability registers. Signed-off-by:
-
Adrian Hunter authored
Signal voltage support is not a quirk, it is a capability. According to the SDHCI specification, support for 1.8V signaling is determined by the presence of one of the capability bits SDHCI_SUPPORT_SDR50, SDHCI_SUPPORT_SDR104, or SDHCI_SUPPORT_DDR50. This is complicated by also supporting eMMC which has 1.8V modes and 1.2V modes. It would be possible to use the transfer mode to determine signal voltage support, except for eMMC DDR52 mode which uses the same capability (MMC_CAP_1_8V_DDR) for 1.8V signaling and 3V signaling. In addition, the mmc core will fail over from one signaling voltage to the next (refer mmc_power_up()) which means SDHCI really needs to validate which voltages are actually supported. Introduce SDHCI flags for signal voltage support and set them based on the supported transfer modes. In general, drivers should prefer to set the supported transfer modes correctly rather than change the signal voltage capability, except in the case where 3V DDR52 is supported but 1.8V is not. Signed-off-by:
-
Adrian Hunter authored
Split sdhci-add_host() in order to further our objective to make sdhci into a library. The split divides code that sets up mmc and sdhci parameters, from code that actually activates things - such as tasklet initialization, requesting the irq, and adding (and starting) the host. This gives drivers an opportunity to change various settings before committing to start the host. Drivers can continue to call sdhci_add_host() but drivers that want to take advantage of the split instead call sdhci_setup_host() followed by __sdhci_add_host(). Signed-off-by:
-
Adrian Hunter authored
Drivers must be able to provide their own implementations for mmc host operations. Consequently, SDHCI should call those not the default implementations. Do that by calling indirectly through the mmc host ops function pointers. Signed-off-by:
-
Chaotian Jing authored
in our host design, rise edge latching is more stable than fall edge latching. so that if rise edge has enough margin, no need scan fall edge. Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
-
Chaotian Jing authored
we did not deal with the read data of CMD21/CMD19 if there is response CRC error of CMD21/CMD19, in this case, eMMC/SD may still in send-data state. therefore, all of next commands cannot get response as device is not in transfer state. for resolving this issue, still need deal with the data receive to make device back to transfer state. Signed-off-by:
-
Chaotian Jing authored
the tune result of hs200 mode at 200Mhz is not suitable for 50Mhz, mmc_select_hs400() will set clock frequency to 50Mhz, use defalut tune setting for 50Mhz to avoid CRC error. Signed-off-by:
-
Chaotian Jing authored
for hs400 mode, should only tune DS delay, should not tune PAD_TUNE for data path. if eMMC will run at hs400 mode, do not tune data while call ops->execute_tuning(). Signed-off-by:
-
Shawn Lin authored
DATA_OVER(the same for RI/TI of IDMAC) interrupt may come up together with data error interrupts. If so, the interrupt routine set EVENT_DATA_ERR to the pending_events and schedule the tasklet but we may still fallback to the IDMAC interrupt case as the tasklet may come up a little late, namely right after the IDMAC interrupt checking. This will casue dw_mmc unmap sg twice. We can easily see it with CONFIG_DMA_API_DEBUG enabled. WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1096 check_unmap+0x7bc/0xb38 dwmmc_exynos 12200000.mmc: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000006d9d2200] [size=128 bytes] Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc4 #26 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c0112b4c>] (unwind_backtrace) from [<c010d888>] (show_stack+0x20/0x24) [<c010d888>] (show_stack) from [<c03fab0c>] (dump_stack+0x80/0x94) [<c03fab0c>] (dump_stack) from [<c0123548>] (__warn+0xf8/0x110) [<c0123548>] (__warn) from [<c01235a8>] (warn_slowpath_fmt+0x48/0x50) [<c01235a8>] (warn_slowpath_fmt) from [<c042ac90>] (check_unmap+0x7bc/0xb38) [<c042ac90>] (check_unmap) from [<c042b25c>] (debug_dma_unmap_sg+0x118/0x148) [<c042b25c>] (debug_dma_unmap_sg) from [<c077512c>] (dw_mci_dma_cleanup+0x7c/0xb8) [<c077512c>] (dw_mci_dma_cleanup) from [<c0773f24>] (dw_mci_stop_dma+0x40/0x50) [<c0773f24>] (dw_mci_stop_dma) from [<c0777d04>] (dw_mci_tasklet_func+0x130/0x3b4) [<c0777d04>] (dw_mci_tasklet_func) from [<c0129760>] (tasklet_action+0xb4/0x150) ..[snip].. ---[ end trace 256f83eed365daf0 ]--- Reported-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Jaehoon Chung authored
Since v2.80a, dwmmc controller introduced the card write threshold for HS400 mode. So CardThrCtl can be supported during write operation, not only read operation. (Note: Only use the write threshold when mode is HS400.) To use more compatible, removed "_rd_" from function name. Signed-off-by:
-
Jaehoon Chung authored
Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO) For removing this, enabled the dto_timer by defaults. It doesn't see any I/O performance degression. In future, dwmmc controller should not use the quirks flag. Signed-off-by:
-
Jaehoon Chung authored
"host->cur_slot" should be assigned to start the request. So it can be the NULL pointer. This patch fixed this error. Signed-off-by:
-
Seung-Woo Kim authored
This patch removes following UBSAN warnings in dw_mci_setup_bus(). UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89cb8>] dw_mci_setup_bus+0x3a0/0x438 [...] UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89c9c>] dw_mci_setup_bus+0x384/0x438 [...] The warnings are caused because of bit shift which is used to filter spamming message for CONFIG_MMC_CLKGATE, but the config is already removed. So this patch just removes the shift. Signed-off-by:
-
Doug Anderson authored
According to the DesignWare state machine description, after we get a "response error" or "response CRC error" we move into data transfer mode. That means that we don't necessarily need to special case trying to deal with the failure right away. We can wait until we are notified that the data transfer is complete (with or without errors) and then we can deal with the failure. It may sound strange to defer dealing with a command that we know will fail anyway, but this appears to fix a bug. During tuning (CMD19) on a specific card on an rk3288-based system, we found that we could get a "response CRC error". Sending the stop command after the "response CRC error" would then throw the system into a confused state causing all future tuning phases to report failure. When in the confused state, the controller would show these (hex codes are interrupt status register): CMD ERR: 0x00000046 (cmd=19) CMD ERR: 0x0000004e (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c CMD ERR: 0x00000104 (cmd=19) CMD ERR: 0x00000104 (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c ... ... It is inherently difficult to deal with the complexity of trying to correctly send a stop command while a data transfer is taking place since you need to deal with different corner cases caused by the fact that the data transfer could complete (with errors or without errors) during various places in sending the stop command (dw_mci_stop_dma, send_stop_abort, etc) Instead of adding a bunch of extra complexity to deal with this, it seems much simpler to just use the more straightforward (and less error-prone) path of letting the data transfer finish. There shouldn't be any huge benefit to sending the stop command slightly earlier, anyway. Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Alim Akhtar <alim.akhtar@gmail.com> Signed-off-by:
-
Ben Dooks authored
The IDMAC_SET_BUFFER1_SIZE() macro modifies des1, but does not check if the value being passed is big or little endian desptire the des1 field being marked as __le32. Fix the issue by ensuring the values are changed from the cpu endian to the descriptor endian by using cpu_to_le32. Spotted whilst doing big endian conversion work on Exynos, and stops the mmc worker thread from stalling. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by:
-
Doug Anderson authored
The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but nothing in the interrupt handler actually handles them and ACKs them. That means that if we ever get an HLE error we'll just keep getting interrupts and we'll wedge things. We really don't expect HLE errors but if we ever get them we shouldn't silently ignore them. Note that I have seen HLE errors while constantly ejecting and inserting cards (ejecting while inserting, etc). Signed-off-by:
-
Jérôme Forissier authored
Enables RPMB support for the on-board eMMC of the HiKey board as well as for eMMC modules connected to the microSD slot. Signed-off-by:
Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by:
-
Shawn Lin authored
The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing gap before it really calls dw_mci_get_cd as mmc_detect_change needs some delay here. Another gain here is that we could save some checkings of card status after sd card been removed. Signed-off-by:
-
Shawn Lin authored
dw_mci_get_cd have already dealt with these for both of internal card-detect and gpio card-detect. Signed-off-by:
-
Ulf Hansson authored
The current value means an mdelay(1) may execute up to 10000000 times, which translates to around ~2.8 hours. This is probably not what the orignal author had in mind. Let's instead use 10s, which is the same value sh_mmcif is using for other timeouts. Signed-off-by: -
Ulf Hansson authored
The sh_mmcif driver is already using a 10s request timeout. Let's also inform the mmc core about this value, as there are situations when it needs to know about it. Signed-off-by: -
Ulf Hansson authored
The sh_mmcif explicity checks for certain commands to decide when to enable HW busy detection. Instead, it should only check the response type as it tells if busy detection is needed. In this way, the mmc core also gets full control whether it thinks busy detection should be done or not. In some specific scenarios, like for ERASE and STOP commands it may decide to fall back to use a CMD13 to poll the card status instead. Signed-off-by: -
Ulf Hansson authored
Enable the capabilities which tells the mmc core to prevent sending SD and SDIO commands during card initialization. In this way, we can also remove the validation of non-supported commands in the ->request() callback. Signed-off-by: -
Ulf Hansson authored
There are host drivers which needs to valdiate for non-supported SD commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD which these host drivers can set to tell the mmc core to skip sending SD commands during card initialization. Signed-off-by: -
Colin Ian King authored
trivial fix to spelling mistake in dev_err message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Chuanxiao Dong authored
sdhci_dumpregs is used to dump registers when error happens. Thus it should use pr_err instead of pr_debug to show more information about the hardware. Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> [Fix whitespace and checkpatch warnings] Signed-off-by:
-
