summaryrefslogtreecommitdiffstats
path: root/drivers/mmc
Commit message (Collapse)AuthorAgeFilesLines
* mmc: dw_mmc: remove the deprecated "supports-highspeed" propertyJaehoon Chung2016-09-261-5/+0
| | | | | | | | | Remvoe the deprecated "supports-highspeed" property. DWMMC controller will not use this property anymore. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: minor cleanup for dw_mci_adjust_fifothShawn Lin2016-09-261-4/+1
| | | | | | | | | msize and rx_wmark are properly initialized, we dont't need to assign them again. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: use macro to define ring buffer sizeShawn Lin2016-09-261-5/+10
| | | | | | | | | | | It's very prone to make mistake as we might forget to replace all PAGE_SIZEs with new values if we try to modify the ring buffer size for whatever reasons. Let's use a macro to define it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: fix misleading error print if failing to do DMA transferShawn Lin2016-09-261-2/+4
| | | | | | | | | | | The original log didn't figure out that we could still finish this transfer by PIO mode even if failing to use DMA. And it should be kept for debug level instead of error one. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: avoid race condition of cpu and IDMACShawn Lin2016-09-261-79/+129
| | | | | | | | | | | | | | | | | | | We could see an obvious race condition by test that the former write operation by IDMAC aiming to clear OWN bit reach right after the later configuration of the same desc, which makes the IDMAC be in SUSPEND state as the OWN bit was cleared by the asynchronous write operation of IDMAC. The bug can be very easy reproduced on RK3288 or similar when we reduce the running rate of system buses and keep the CPU running faster. So as two separate masters, IDMAC and cpu write the same descriptor stored on the same address, and this should be protected by adding check of OWN bit before preparing new descriptors. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: split out preparation of desc for IDMAC32 and IDMAC64Shawn Lin2016-09-261-70/+79
| | | | | | | | | | | | | We intend to add more check for descriptors when preparing desc. Let's spilt out the separate body to make the dw_mci_translate_sglist not so lengthy. After spliting out these two functions, we could remove dw_mci_translate_sglist and call both of them when staring idmac. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: don't try to switch block size for dual rate modeZiyuan Xu2016-09-261-1/+2
| | | | | | | | | | Per spec, block size should always be 512 bytes for dual rate mode, so any attempts to switch the block size under dual rate mode should be neglected. Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-of-arasan: Set controller to test mode when no CD bitZach Brown2016-09-262-1/+28
| | | | | | | | | | | | | | | | The sdhci controller on xilinx zynq devices will not function unless the CD bit is provided. http://www.xilinx.com/support/answers/61064.html In cases where it is impossible to provide the CD bit in hardware, setting the controller to test mode and then setting inserted to true will get the controller to function without the CD bit. When the device has the property xlnx,fails-without-test-cd the driver changes the controller to test mode and sets test inserted to true to make the controller function. Signed-off-by: Zach Brown <zach.brown@ni.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: tmio: add eMMC supportWolfram Sang2016-09-262-12/+29
| | | | | | | | | We need to add R1 without CRC support, refactor the bus width routine a little and extend a quirk check. To support "non-removable;" we need a workaround which will be hopefully removed when reworking PM soon. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: rtsx_usb: use new macro for R1 without CRCWolfram Sang2016-09-261-1/+1
| | | | | Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: rtsx_pci: use new macro for R1 without CRCWolfram Sang2016-09-261-1/+1
| | | | | Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: card: do away with indirection pointerLinus Walleij2016-09-264-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | We have enough vtables in the kernel as it is, we don't need this one to create even more artificial separation of concerns. As is proved by the Makefile: obj-$(CONFIG_MMC_BLOCK) += mmc_block.o mmc_block-objs := block.o queue.o block.c and queue.c are baked into the same mmc_block.o object. So why would one of these objects access a function in the other object by dereferencing a pointer? Create a new block.h header file for the single shared function from block to queue and remove the function pointer and just call the queue request function. Apart from making the code more readable, this also makes link optimizations possible and probably speeds up the call as well. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-acpi: Set MMC_CAP_CMD_DURING_TFR for Intel eMMC controllersAdrian Hunter2016-09-261-1/+1
| | | | | | | Set MMC_CAP_CMD_DURING_TFR for Intel BYT and related eMMC host controllers. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-pci: Set MMC_CAP_CMD_DURING_TFR for Intel eMMC controllersAdrian Hunter2016-09-261-0/+1
| | | | | | | Set MMC_CAP_CMD_DURING_TFR for Intel BYT and related eMMC host controllers. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Support cap_cmd_during_tfr requestsAdrian Hunter2016-09-261-4/+17
| | | | | | | | | | | | | | | | | | | | Now SDHCI supports commands during transfer, enable support for the core API. There are 3 small changes needed: First, auto-CMD12 cannot be used with a cap_cmd_during_tfr request because the host controller cannot expect the command line to be available. Secondly, a cap_cmd_during_tfr request must not send a stop command, again because the host controller cannot expect the command line to be available. Thirdly, when a cap_cmd_during_tfr command completes, use mmc_command_complete() to notify the upper layers that the command line is now available for further commands. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc_test: Add tests for sending commands during transferAdrian Hunter2016-09-261-0/+308
| | | | | | | | | | | | | | | | | | Add 6 tests for sending commands during transfer. The tests are: * Commands during read - no Set Block Count (CMD23). * Commands during write - no Set Block Count (CMD23). * Commands during read - use Set Block Count (CMD23). * Commands during write - use Set Block Count (CMD23). * Commands during non-blocking read - use Set Block Count (CMD23). * Commands during non-blocking write - use Set Block Count (CMD23). For a range of transfer sizes, the tests start an ongoing data transfer and then repeatedly send the status command (CMD13) while the transfer continues. The tests pass if all requests complete with no errors. The host controller driver must support MMC_CAP_CMD_DURING_TFR. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Add support for sending commands during data transferAdrian Hunter2016-09-261-6/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A host controller driver exposes its capability using caps flag MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the upper layers when the command line is available for further commands by calling mmc_command_done(). Because of that, the driver will not then automatically send STOP commands, and it is the responsibility of the upper layer to send a STOP command if it is required. For requests submitted through the mmc_wait_for_req() interface, the caller sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact not to wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete by calling mmc_wait_for_req_done() which is now exported. For requests submitted through the mmc_start_req() interface, the caller again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does not wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete in the normal way i.e. calling mmc_start_req() again. Irrespective of how a cap_cmd_during_tfr request is started, mmc_is_req_done() can be called if the upper layer needs to determine if the request is done. However the appropriate waiting function (either mmc_wait_for_req_done() or mmc_start_req()) must still be called. The implementation consists primarily of a new completion mrq->cmd_completion which notifies when the command line is available for further commands. That completion is completed by mmc_command_done(). When there is an ongoing data transfer, calls to mmc_wait_for_req() will automatically wait on that completion, so the caller does not have to do anything special. Note, in the case of errors, the driver may call mmc_request_done() without calling mmc_command_done() because mmc_request_done() always calls mmc_command_done(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-brcmstb: Fix incorrect capabilityJaedon Shin2016-09-261-0/+3
| | | | | | | | | | | Clear incorrect SDHCI_CAN_64BIT capability on Broadcom MIPS based SoCs. The MIPS based SoCs are using ADMA only, but the several SoCs have the incorrect capability bit about ADMA 64-bit. The "brcm,bcm7425-sdhci" is compatible string for MIPS based SoC. Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sunxi: add support for A64 mmc controllerIcenowy Zheng2016-09-261-0/+79
| | | | | | | | | A64 SoC features a MMC controller which need only the mod clock, and can calibrate delay by itself. This patch adds support for the new MMC controller IP core. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Optimize the mmc erase size alignmentBaolin Wang2016-09-261-8/+26
| | | | | | | | | | In most cases the 'card->erase_size' is power of 2, then the round_up/down() function is more efficient than '%' operation when the 'card->erase_size' is power of 2. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Factor out the alignment of erase sizeBaolin Wang2016-09-261-16/+32
| | | | | | | | | | In order to clean up the mmc_erase() function and do some optimization for erase size alignment, factor out the guts of erase size alignment into mmc_align_erase_size() function. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: davinci: remove incorrect NO_IRQ useArnd Bergmann2016-09-261-2/+4
| | | | | | | | | | platform_get_irq() returns an error value on failure, not NO_IRQ, so the error handling here could never work. This changes the code to propagate the error value instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sh_mobile_sdhi: Add r8a7796 supportAi Kyuse2016-09-261-0/+1
| | | | | | | | | Add support for r8a7796 SoC. Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Use a default maximum erase timeoutUlf Hansson2016-09-261-7/+10
| | | | | | | | | | | | | | | | In cases when the host->max_busy_timeout isn't specified, the calculated number of maximum discard sectors defaults to UINT_MAX. This may cause a too long timeout for a discard request. Avoid this by using a default maximum erase timeout of 60s, used when we calculate the maximum number of sectors that are allowed to be discarded per request. Do note that the minimum number of sectors to be discarded is still at least one "preferred erase size". Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
* mmc: tegra: Mark 64-bit DMA broken on Tegra124Thierry Reding2016-09-261-1/+26
| | | | | | | | | | | | | | | | | | | | According to the TRM, the SD/MMC controller on Tegra124 supports 34-bit addressing, but testing shows that this doesn't work. On a device which has more than 2 GiB of RAM and LPAE enabled, buffer allocations can use addresses above the 32-bit boundary. One way to work around this would be to enable IOMMU physical to virtual address translations for the SD/MMC controllers, but that's not easy to implement without breaking existing use-cases. It's also not obvious why 34-bit addressing doesn't work as advertised. In order to fix this for existing users, add the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk for now. Reported-by: Paul Kocialkowski <contact@paulk.fr> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-of-arasan: Properly set corecfg_clockmultiplier on rk3399Shawn Lin2016-09-261-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | corecfg_clockmultiplier indicates clock multiplier value of programmable clock generator which should be the same value of SDHCI_CAPABILITIES_1. The default value of the register, corecfg_clockmultiplier, is 0x10. But actually it is a mistake by designer as our intention was to set it to be zero which means we don't support programmable clock generator. So we have to make it to be zero on bootloader which seems work fine until now. But now we find an issue that when deploying genpd support for it, the remove callback will trigger the genpd to poweroff the power domain for sdhci-of-arasan which manage the controller, phy and corecfg_* stuff. So when we do bind/unbind the driver, we have already reinit the controller and phy, but without doing that for corecfg_*. Regarding to only the corecfg_clockmultipler is wrong, let's fix it by explicitly marking it to be zero when probing. With this change, we could do bind/unbind successfully. Reported-by: Ziyuan Xu <xzy.xu@rock-chips.com> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Ziyuan Xu <xzy.xu@rock-chips.com> Tested-by: Ziyuan Xu <xzy.xu@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* sdhci-pci: enable SD card interface on MerrifieldAndy Shevchenko2016-09-261-1/+4
| | | | | | | | | Intel Merrifield provides an interface to an external SD card. Enable it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* sdhci-pci: enable SDIO interface on Intel MerrifieldAndy Shevchenko2016-09-261-0/+5
| | | | | | | | | | | Intel Merrifield is known to have an SDIO interface and on Intel Edison board a WiFi card is wired to it. Enable the interface here to allow WiFi card enumeration. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* sdhci-pci: refactor intel_mrfld_mmc_probe_slot()Andy Shevchenko2016-09-261-6/+11
| | | | | | | | | Refactor intel_mrfld_mmc_probe_slot() to use switch case. The change allows to add a support for SD and SDIO interfaces without any pain. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: k3: UHS-SD card for Hisilicon HikeyJin Guojun2016-09-261-0/+6
| | | | | | | | | Hisilicon Hikey have no tuning function in dw_mmc-k3.c, so we must do the tuning function stub when we init UHS card. Signed-off-by: Jin Guojun <kid.jin@hisilicon.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: return -EILSEQ for EBE and SBE errorShawn Lin2016-09-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following log we found indicate the fact that dw_mmc didn't treat EBE or SBE as a similar problem as CRC error. -EIO is quite not informative as it may indicate that the device is broken rather than that of tuning stuff. ... [ 89.057226] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 [ 89.058811] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 [ 89.059415] bcmsdh_sdmmc: Failed to Read byte F1:@0x1000e=ff, Err: -84 [ 89.254248] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 199 [ 89.273912] dhd_set_suspend: Remove extra suspend setting [ 89.274478] dhd_enable_packet_filter: enter, value = 0 64 bytes from 112.90.83.112: icmp_seq=24 ttl=53 time=1321 ms 64 bytes from 112.90.83.112: icmp_seq=25 ttl=53 time=319 ms 64 bytes from 112.90.83.112: icmp_seq=26 ttl=53 time=69.8 ms 64 bytes from 112.90.83.112: icmp_seq=27 ttl=53 time=37.5 ms ... For the host, when failing to sample cmd's response due to tuning stuff, we still return -EIO as it's quite vague to figure out whether it related to signal or just the broken devices, especially for the card type detection when booting kernel as all things go well but the cmd set used. But for the data phase, if receiving the cmd's response which carriess data transfer, we should have more confidence that it is very probably related to the tuning stuff. Just as the log shown above, we sometimes suffer too much this kind of pain as the dw_mmc return -EIO for the case, so mmc-core will not do retune and caller drivers like bcm's wifi driver, still retry the failure more and more until dw_mmc finally generate CRC. Adrian suggested that drivers who care the specific cases should call mmc_retune_needed rather than doing it in mmc core. It makes sense but I'm considering that -EILSEQ actually means illegal sequence , so we use it for CRC cases. Meanwhile, SBE/EBE indicate the illegal sequence of start bit or end bit for data0~7. So I realize that we should use -EILSEQ for them both as well CRC cases. Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: add reset support to dwmmc host controllerGuodong Xu2016-09-261-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | Dwmmc host controller may in unknown state when entering kernel boot. One example is when booting from eMMC, bootloader need initialize MMC host controller into some state so it can read. In order to make sure MMC host controller in a clean initial state, this reset support is added. With this patch, a 'resets' property can be added into dw_mmc device tree node. The hardware logic is: dwmmc host controller IP receives a reset signal from a 'reset provider' (eg. power management unit). The 'resets' property points to this reset signal. So, during dwmmc driver probe, it can use this signal to reset itself. Refer to [1] for more information. [1] Documentation/devicetree/bindings/reset/reset.txt Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Xinwei Kong <kong.kongxinwei@hisilicon.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: remove the unnecessary IS_ERR() checking for ciu/biu clockJaehoon Chung2016-09-261-9/+4
| | | | | | | | | | If ciu/biu clock are NULL, clk_disable_unprepare should be just returned. In clk_disable_unprepare(), already checked whether clk is error or NULL. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: remove parsing for each slot subnodeShawn Lin2016-09-261-43/+0
| | | | | | | | | | | | | | | | | | | The intention to remove it comes from the conflict of what the mmc-core does with the way dw_mmc treats disable-wp. We could see that 'disable-wp' is supported by core but it's deprecated by dw_mmc as we don't expect it to be existed for each slot subnode but should be in the parent node. Based on searching for all the upstream dts using dw_mmc, we're confident that none of them use the deprecated way. Maybe we should take old dtb in consideration but it was a flag day since the time we was considering to take it away. The fact is that there are none of dts using the deprecated way since v3.18 or even earlier. So personally I don't believe the old dtb would/could bootup current kernel(may not?). Let's remove it now. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: dw_mmc: exynos: Warn if HS400 is being used on non-Exynos5420 chipsetKrzysztof Kozlowski2016-09-261-1/+5
| | | | | | | | | | | Chipsets before Exynos5420 did not support HS400 so if MMC core tries to configure HS400 timing, this might or might not work. Warn in such cases because this is DTB misconfiguration. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: block: don't use CMD23 with very old MMC cardsDaniel Glöckner2016-09-261-1/+2
| | | | | | | | | | | | | | | | | | | | CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1. Older versions of the specification allowed to terminate multi-block transfers only with CMD12. The patch fixes the following problem: mmc0: new MMC card at address 0001 mmcblk0: mmc0:0001 SDMB-16 15.3 MiB mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 ... blk_update_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table Signed-off-by: Daniel Glöckner <dg@emlix.com> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Remove ->platform_init() callback as it's no longer usedUlf Hansson2016-09-262-8/+0
| | | | | | | | | | | | The commit 1ef5e49e46b9 ("mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version") moved sdhci-of-esdhc away from using the ->platform_init() callback. As it was the only user of it and that it seems reasonable to believe that it won't be needed again, let's just remove it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
* mmc: sdhci-pci: Convert to use managed functions (part2)Andy Shevchenko2016-09-262-29/+6
| | | | | | | | | | | The commit 52ac7acf412b ("mmc: sdhci-pci: Convert to use managed functions pcim_* and devm_*") converted ->probe() / ->remove() functions to use device managed resource API. Here is a follow up to cover sdhci_pci_probe_slot() and sdhci_pci_remove_slot(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdio: deploy error handling instead of triggering BUG_ONShawn Lin2016-09-262-23/+33
| | | | | | | | | | | | | | | | | | | | | | When using mmc_io_rw_extended, it's intent to avoid null pointer of card and invalid func number. But actually it didn't prevent that as the seg_size already use the card. Currently the wrapper function sdio_io_rw_ext_helper already use card before calling mmc_io_rw_extended, so we should move this check to there. As to the func number, it was token from '(ocr & 0x70000000) >> 28' which should be enough to guarantee that it won't be larger than 7. But we should prevent the caller like wifi drivers modify this value. So let's move this check into sdio_io_rw_ext_helper either. Also we remove the BUG_ON for mmc_send_io_op_cond since all possible paths calling this function are protected by checking the arguments in advance. After deploying these changes, we could not see any panic within SDIO API even if func drivers abuse the SDIO func APIs. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: block: remove the check of packed for packed request routineShawn Lin2016-09-261-12/+12
| | | | | | | | | | | | | | | | | | | | packed should always exist without calling its cleanup function explicitly. Moreover, we have use it when preparing packed list. So I don't believe we should ever fall into this check again when doing mmc_blk_packed_hdr_wrq_prep or mmc_blk_end_packed_req,etc. And the code of mmc_blk_end_packed_req is trying to use packed before checking it which makes it quite weird. This patch is trying to remove these two checks and move it to the mmc_blk_prep_packed_list. If we find packed is null, then we should never use MMC_BLK_PACKED_CMD. By doing this, we could fall back to non-packed request if finding null packed, though it's impossible theoretically. After removing these two BUG_ONs, we also remove all other similar checks within the routine of mmc_blk_issue_rw_rq which checks the error handling of packed request. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Add error message when switching fails in mmc_select_hs()Jungseung Lee2016-09-261-4/+5
| | | | | | | | | | | | | The switch failure message in mmc_select_timing() had been removed since that is invalid: commit 0400ed0a083a ("mmc: core: remove the invalid message in mmc_select_timing") Now, in the case when mmc_select_hs() return error in mmc_select_timing(), there is nothing to print failure message. Let's make for mmc_select_hs() print message itself in the failure case. Signed-off-by: Jungseung Lee <js07.lee@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: host: sh_mobile_sdhi: don't populate unneeded functionsWolfram Sang2016-09-261-2/+8
| | | | | | | | | | | Populating card_busy caused a side-effect on a chip variant we don't have documentation for (r8a73a4). So, enable it and voltage switching only on devices known to support those features. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Fixes: 452e5eef6d31 ("mmc: tmio: Add UHS-I mode support")
* mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhiWolfram Sang2016-09-263-8/+10
| | | | | | | | | | card_busy is only used/tested on SDHI for R-Car Gen2 and later. Move it to the SDHI driver, so we can then activate it conditionally depending on the SDHI type. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sunxi-mmc: change idma descriptor to __le32Michael Weiser2016-09-261-12/+15
| | | | | | | | | | | | | | | The sunxi-mmc driver does not take into account the processor may be big endian when writing the DMA descriptors. This causes cards not to be detected when running a big-endian kernel. Change the descriptors for IDMA to use __le32 and ensure they are suitably swapped before writing. Tested successfully on the Cubieboard2. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: linux-mmc@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sunxi: Check the value returned by clk_round_rateJean-Francois Moine2016-09-261-3/+9
| | | | | | | | clk_round_rate() may return an error. Check it. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-of-arasan: Don't power PHY w/ slow/no clockDouglas Anderson2016-09-261-15/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PHY intended to be used with the Arasan SDHCI 5.1 controller has trouble turning on when the card clock is slow or off. Strangely these problems appear to show up consistently on some boards while other boards work fine, but on the boards where it shows up the problem reproduces 100% of the time and is quite consistent in its behavior. These problems can be fixed by always making sure that we power on the PHY (and turn on its DLL) when the card clock is faster than about 50 MHz. Once on, we need to make sure that we never power down the PHY / turn off its DLL until the clock is faster again. We'll add logic for handling this into the sdhci-of-arasan driver. Note that right now the only user of a PHY in the sdhci-of-arasan driver is arasan,sdhci-5.1. It's presumed that all arasan,sdhci-5.1 PHY implementations need this workaround, so the logic is only contingent on having a PHY to control. If future Arasan controllers don't have this problem we can add code to decide if we want this flow or not. Also note that we check for slow clocks by checking for <= 400 kHz rather than checking for 50 MHz. This keeps things the most consistent and also means we can power the PHY on at max speed (where the DLL will lock fastest). Presumably anyone who intends to run with a card clock of < 50 MHz and > 400 kHz will be running on a device where this problem is fixed anyway. I believe this brings some resolution to the problems reported before. See the commit 6fc09244d74d ("mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes"). Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Do not allow tuning procedure to be interruptedChristopher Freeman2016-09-261-1/+1
| | | | | | | | | | | | | | | wait_event_interruptible_timeout() will return early if the blocked process receives a signal, causing the driver to abort the tuning procedure and possibly leaving the controller in a bad state. Since the tuning command is expected to complete quickly (<50ms) and we've set a timeout, use wait_event_timeout() instead. Signed-off-by: Christopher Freeman <cfreeman@nvidia.com> Tested-by: Robert Foss <robert.foss@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-esdhc-imx: correct the max timeout countHaibo Chen2016-09-261-1/+2
| | | | | | | | | | | i.MX USDHC Reference Manual has a mistake, for the register SYS_CTRL, the DTOCV(bit 19~16) means the data timeout counter value. When DTOCV is set to 0xF, it means SDCLK << 29, not SDCLK << 28. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Dong Aisheng <aisheng.dong@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-esdhc-imx: do not touch other bit when config DTOCVHaibo Chen2016-09-261-1/+3
| | | | | | | | | | Now, when call esdhc_set_timeout() to set the data timeout counter value, IPP_RST_N(bit 23) is wrongly affected. This patch add a mask to avoid this. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Dong Aisheng <aisheng.dong@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci-brcmstb: Delete owner assignmentMarkus Elfring2016-09-261-1/+0
| | | | | | | | | | The field "owner" is set by core. Thus delete an extra initialisation. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 07:22:26 +0000