summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/host
AgeCommit message (Collapse)AuthorFilesLines
2018-04-04mmc: tmio: Fix error handling when issuing CMD23Masaharu Hayakawa1-1/+1
If an error was detected when CMD23 was issued, command sequence should be terminated with errors and CMD23 should be issued after retuning. Fixes: 8b22c3c18be5 ("mmc: tmio: add CMD23 support") Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: <stable@vger.kernel.org> # 4.13+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-04-04mmc: jz4740: Fix race condition in IRQ mask updateAlex Smith1-1/+1
A spinlock is held while updating the internal copy of the IRQ mask, but not while writing it to the actual IMASK register. After the lock is released, an IRQ can occur before the IMASK register is written. If handling this IRQ causes the mask to be changed, when the handler returns back to the middle of the first mask update, a stale value will be written to the mask register. If this causes an IRQ to become unmasked that cannot have its status cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ, then we can end up stuck with the same IRQ repeatedly being fired but not handled. Normally the MMC IRQ handler attempts to clear any unexpected IRQs by writing IREG, but for those that cannot be cleared in this way then the IRQ will just repeatedly fire. This was resulting in lockups after a while of using Wi-Fi on the CI20 (GitHub issue #19). Resolve by holding the spinlock until after the IMASK register has been updated. Cc: stable@vger.kernel.org Link: https://github.com/MIPS/CI20_linux/issues/19 Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.") Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Alex Smith <alex.smith@imgtec.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-04-03Merge tag 'mmc-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds19-208/+791
Pull MMC updates from Ulf Hansson: "MMC core: - Export host capabilities through debugfs - Export card RCA register via sysfs - Improve card initializing sequence while enabling 4-bit bus - Export a function to enable/disable wakeup for card detect IRQ MMC host: - dw_mmc: Add support for new hi3798cv200 variant - dw_mmc: Remove support for some deprecated DT properties - mediatek: Add support for new variant used on MT7622 SoC - sdhci: Improve wakeup support for SDIO IRQs - sdhci: Improve wakeup support for card detect IRQs - sdhci-omap: Add tuning support - sdhci_omap: Add UHS-I mode support - sunxi: Prepare for runtime PM support via a few re-factorings - tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property - tmio/renesas_sdhi: Consolidate code supporting write protect - tmio: Improve DMA vs PIO handling - tmio: Add support for IP-builtin card detection logic" * tag 'mmc-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (55 commits) mmc: renesas_sdhi: replace EXT_ACC with HOST_MODE mmc: update sdio_claim_irq documentation mmc: Export host capabilities to debugfs. mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards mmc: block: fix updating ext_csd caches on ioctl call mmc: sunxi: Set our device drvdata earlier mmc: sunxi: Move the reset deassertion before enabling the clocks mmc: sunxi: Move resources management to separate functions mmc: dw_mmc: add support for hi3798cv200 specific extensions of dw-mshc dt-bindings: mmc: add bindings for hi3798cv200-dw-mshc mmc: core: Export card RCA register via sysfs mmc: renesas_sdhi: fix WP detection mmc: core: Use memdup_user() rather than duplicating its implementation mmc: dw_mmc-rockchip: correct property names in debug mmc: sd: Remove redundant err assignment from mmc_read_switch mmc: sdio: Check the return value of sdio_enable_4bit_bus mmc: core: Don't try UHS-I mode if 4-bit mode isn't supported arm64: dts: hi3660: remove 'num-slots' property for dwmmc ARM: dts: lpc18xx: remove 'num-slots' property for dwmmc arm64: dts: stratix10: remove 'num-slots' property for dwmmc ...
2018-04-02Merge tag 'arch-removal' of ↵Linus Torvalds3-699/+0
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pul removal of obsolete architecture ports from Arnd Bergmann: "This removes the entire architecture code for blackfin, cris, frv, m32r, metag, mn10300, score, and tile, including the associated device drivers. I have been working with the (former) maintainers for each one to ensure that my interpretation was right and the code is definitely unused in mainline kernels. Many had fond memories of working on the respective ports to start with and getting them included in upstream, but also saw no point in keeping the port alive without any users. In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. In contrast, CPU instruction sets that remain popular and have actively maintained kernel ports tend to all be used across multiple licensees. [ See the new nds32 port merged in the previous commit for the next generation of "one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem" - Linus ] The removal came out of a discussion that is now documented at https://lwn.net/Articles/748074/. Unlike the original plans, I'm not marking any ports as deprecated but remove them all at once after I made sure that they are all unused. Some architectures (notably tile, mn10300, and blackfin) are still being shipped in products with old kernels, but those products will never be updated to newer kernel releases. After this series, we still have a few architectures without mainline gcc support: - unicore32 and hexagon both have very outdated gcc releases, but the maintainers promised to work on providing something newer. At least in case of hexagon, this will only be llvm, not gcc. - openrisc, risc-v and nds32 are still in the process of finishing their support or getting it added to mainline gcc in the first place. They all have patched gcc-7.3 ports that work to some degree, but complete upstream support won't happen before gcc-8.1. Csky posted their first kernel patch set last week, their situation will be similar [ Palmer Dabbelt points out that RISC-V support is in mainline gcc since gcc-7, although gcc-7.3.0 is the recommended minimum - Linus ]" This really says it all: 2498 files changed, 95 insertions(+), 467668 deletions(-) * tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (74 commits) MAINTAINERS: UNICORE32: Change email account staging: iio: remove iio-trig-bfin-timer driver tty: hvc: remove tile driver tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers serial: remove tile uart driver serial: remove m32r_sio driver serial: remove blackfin drivers serial: remove cris/etrax uart drivers usb: Remove Blackfin references in USB support usb: isp1362: remove blackfin arch glue usb: musb: remove blackfin port usb: host: remove tilegx platform glue pwm: remove pwm-bfin driver i2c: remove bfin-twi driver spi: remove blackfin related host drivers watchdog: remove bfin_wdt driver can: remove bfin_can driver mmc: remove bfin_sdh driver input: misc: remove blackfin rotary driver input: keyboard: remove bf54x driver ...
2018-03-26mmc: remove bfin_sdh driverArnd Bergmann3-699/+0
The blackfin architecture is getting removed, so this one is obsolete now as well. Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Aaron Wu <aaron.wu@analog.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-22mmc: renesas_sdhi: replace EXT_ACC with HOST_MODEMasaharu Hayakawa1-3/+3
All our documentation says HOST_MODE, we don't really know where EXT_ACC came from. Rename it to reduce the confusion. Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-21Merge branch 'fixes' into nextUlf Hansson1-1/+1
2018-03-21mmc: sdhci-acpi: Fix IRQ 0Adrian Hunter1-1/+1
Zero is a valid IRQ number and is being used on some CHT tablets. Stop treating it as an error. Reported-by: Luke Ross <luke@lukeross.name> Fixes: 1b7ba57ecc86 ("mmc: sdhci-acpi: Handle return value of platform_get_irq") Cc: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-16Merge branch 'fixes' into nextUlf Hansson1-2/+4
2018-03-16mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occursEvgeniy Didin1-2/+4
It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout overflow calculation failure: 1. soft-reset is called 2. driver restarts dma 3. descriptors states are checked, one of descriptor is owned by the IDMAC. 4. driver can't use DMA and then switches to PIO mode. Failure was already fixed in: https://www.spinics.net/lists/linux-mmc/msg48125.html. Behaviour while soft-reset is not something we except or even want to happen. So we switch from dw_mci_idmac_reset to dw_mci_idmac_init, so descriptors are cleaned before starting dma. And while at it explicitly zero des0 which otherwise might contain garbage as being allocated by dmam_alloc_coherent(). Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15Merge branch 'fixes' into nextUlf Hansson1-1/+7
2018-03-15mmc: sunxi: Set our device drvdata earlierMaxime Ripard1-1/+1
As soon as the pm_runtime_enable hook is called, our runtime_suspend and runtime_resume hooks can be called as well. However, we only set the device drvdata that we will use after we have registered into the MMC core. Move that earlier so that we don't have a race that could lead to a crash. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sunxi: Move the reset deassertion before enabling the clocksMaxime Ripard1-18/+18
As per Allwinner guidelines, the reset line should be deasserted before turning the clocks on. Implement it in our driver as well. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sunxi: Move resources management to separate functionsMaxime Ripard1-60/+82
We've had all our resources management, and especially the clocks and reset sequence, done directly as part of the probe. As we want to implement runtime_pm, we'll obviously want to have that moved outside of the probe so that we can call do it in our runtime suspend and resume hooks without too much duplication. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: add support for hi3798cv200 specific extensions of dw-mshctianshuliang4-0/+218
Hi3798CV200 SoC extends the dw-mshc controller for additional clock and bus control. Add support for these extensions. Signed-off-by: tianshuliang <tianshuliang@hisilicon.com> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433Jaehoon Chung1-1/+7
Before enabling the clock, dwmmc exynos driver is trying to access the register. Then the kernel panic can be occurred. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: renesas_sdhi: fix WP detectionWolfram Sang2-4/+0
Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI which incorrectly disabled WP altogether instead of only disabling the internal mechanism. Since the whole WP handling has been reworked, we can simply disable this capability to re-enable WP GPIOs. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc-rockchip: correct property names in debugJohn Keeping1-2/+2
Following up the device tree fixed in commits e78c637127ee ("ARM: dts: rockchip: Fix DWMMC clocks") and ca9eee95a2de ("arm64: dts: rockchip: Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct property name in the debug output if clocks are not found. Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: remove the deprecated "num-slots"Jaehoon Chung3-7/+0
'num-slots' property had already deprecated. Remove the 'nom-slots' property that is kept to maintain the compatibility. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: remove the deprecated "clock-freq-min-max" propertyJaehoon Chung1-11/+4
'clock-freq-min-max' property had already deprecated. Remove the 'clock-freq-min-max' property that is kept to maintain the compatibility. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05Merge branch 'fixes' into nextUlf Hansson1-3/+6
2018-03-05mmc: mediatek: add support for MT7622 SoCSean Wang1-0/+12
Just applying the existing logic and adding its own characteristics into the space pointed by an extra entry of struct of_device_id to have support of MT7622 SoC. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Tested-by: Jumin Li <jumin.li@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-pci: Respect PM flags when enabling card detect GPIO IRQ wakeupAdrian Hunter1-4/+19
Commit 03dbaa04a2e5 ("mmc: slot-gpio: Add support to enable irq wake on cd_irq") enabled wakeup at initialization. However, users also want to control it from sysfs power/wakeup attribute. That means the driver needs to check the PM flags before enabling it in the suspend callback. Add support for that in sdhci-pci, which is the only driver presently using the MMC_CAP_CD_WAKE flag, and remove the enabling in mmc_gpiod_request_cd_irq() Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci: Do not unnecessarily enable wakeup for SDIO card interruptAdrian Hunter1-2/+7
Do not enable wakeup for SDIO card interrupt unless the SDIO function driver has requested it which is indicated by mmc_card_wake_sdio_irq(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci: Do not unnecessarily enable wakeup for card detect interruptAdrian Hunter1-1/+9
Do not unnecessarily enable card detect wakeup in the cases that the card is not removable or a GPIO is used for card detect. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-pci: Get rid of glk_cqe_enable()Adrian Hunter1-19/+1
Now that tuning no longer leaves the Buffer Read Enable bit set (refer intel_execute_tuning()), glk_cqe_enable() is no longer needed. Get rid of it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: ushc: Remove bogus check of usb_submit_urbShawn Lin1-2/+0
Not sure why it was there in the first place, but it's obviously useless check, so let's remove it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: update kernel-doc comments for dw_mciAlexey Roslyakov1-10/+9
cur_slot and num_slots has been removed from struct dw_mci in 42f989c002f2. Unfortunately, inline documentation was not updated so far. Fix @lock field documentation in Locking section. Move @mrq field of struct dw_mci_slot mention closer to it description, so no one could miss this slightest detail. Couple of code style fixes as a bonus. Signed-off-by: Alexey Roslyakov <alexey.roslyakov@gmail.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: Remove prev_state and state assignment for STATE_SENDING_CMDShawn Lin1-1/+0
Clang reports a compile warning: drivers/mmc/host/dw_mmc.c:2124:5: warning: Value stored to 'prev_state' is never read By checking the code, prev_state and state assignment for STATE_SENDING_CMD is indeed never used after jumping to unlock tag. So remove it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: Convert to use DEFINE_SHOW_ATTRIBUTEShawn Lin1-26/+2
Use the newly added macro to simply to the code. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: remove useless TMIO_MASK_CMD handling in tmio_mmc_host_probe()Masahiro Yamada1-3/+0
TMIO_MASK_CMD is properly enabled in tmio_mmc_start_command(). We have no reason to set it up in tmio_mmc_host_probe(). (If we really wanted to set it in the probe, we would have to do likewise when resuming.) Even worse, the following code is extremely confusing: _host->sdcard_irq_mask &= ~irq_mask; The logic is opposite between "->sdcard_irq_mask" and "irq_mask". The intention is not clear at a glance. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: clear force_pio flag before starting data transferMasahiro Yamada1-3/+1
Currently, force_pio is cleared when the driver exits. Then, it resulted in clearing it in multiple places since MMC drivers in general have multiple exit points. tmio_mmc_reset_work - bails out on timeout tmio_process_mrq - error out when it cannot send a command tmio_mmc_finish_request - successful exit This is error-prone since we may miss to cover all bail-out points. To simplify the code, the data structure should be initialized just before used since we have a single entrance. force_pio is only used for data transfer, so tmio_mmc_start_data() will be a suitable place to clear this flag. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: move TMIO_MASK_{READOP, WRITEOP} handling to correct placeMasahiro Yamada3-20/+10
As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ} are asserted for DMA mode as well as for PIO. I need to disable the those IRQs in dma_ops->start hook, otherwise the DMA transfer fails with the following error message: PIO IRQ in DMA mode! Renesas chips are the same cases since I see their dma_ops->start hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!). If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling should be entirely moved to the core. tmio_mmc_cmd_irq() will be a suitable place to disable them. The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd. /* Unmask the IRQs we want to know about */ if (!_host->chan_rx) irq_mask |= TMIO_MASK_READOP; if (!_host->chan_tx) irq_mask |= TMIO_MASK_WRITEOP; At this point, _host->{chan_rx,chan_tx} are _always_ NULL because tmio_mmc_request_dma() is called after this code. Consequently, TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not. Remove this pointless code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: fix never-detected card insertion bugMasahiro Yamada1-4/+8
The TMIO mmc cannot detect the card insertion in native_hotplug mode if the driver is probed without a card inserted. The reason is obvious; all IRQs are disabled by tmio_mmc_host_probe(), as follows: tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL); The card event IRQs are first enabled by tmio_mmc_start_command() as follows: if (!host->native_hotplug) irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT); tmio_mmc_enable_mmc_irqs(host, irq_mask); If the driver is probed without a card, tmio_mmc_start_command() is never called in the first place. So, the card is never detected. The card event IRQs must be enabled in probe/resume functions. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: support IP-builtin card detection logicMasahiro Yamada1-1/+12
A card detect GPIO is set up only for platforms with "cd-gpios" DT property or TMIO_MMC_USE_GPIO_CD flag. However, the driver core always uses mmc_gpio_get_cd, which just fails with -ENOSYS if ctx->cd_gpio is unset. The bit 5 of the status register provides the current signal level of the CD line. Allow to use it if the GPIO is unused. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systemsEvgeniy Didin1-3/+6
The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") made changes, which cause multiply overflow for 32-bit systems. The broken timeout calculations leads to unexpected ETIMEDOUT errors and causes stacktrace splat (such as below) during normal data exchange with SD-card. | Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1 | - Info: Finished target initialization. | mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd | response 0x900, card status 0x0 DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so code gets compiled on all 32-bit platforms as opposed to usage of DIV_ROUND_UP when we may only compile stuff on a very few arches. Lets cast this multiply to u64 type to prevent the overflow. Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") Tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: <stable@vger.kernel.org> # 4.14 Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: deprecate "toshiba, mmc-wrprotect-disable" DT propertyMasahiro Yamada1-0/+5
This property is equivalent to "disable-wp" defined in Documentation/devicetree/bindings/mmc/mmc.txt The TMIO MMC core calls mmc_of_parse(), and it sets MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present. We do not need a vendor-specific property to do the same thing. Let's remove the description from the dt-binding to prevent new boards from using it. I am keeping the driver code for existing DT files, but added comments that this is deprecated. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLEMasahiro Yamada1-3/+2
The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT. No platform defines this flag any more. Remove. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flagMasahiro Yamada1-3/+3
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and "toshiba,mmc-wrprotect-disable" at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flagMasahiro Yamada2-11/+11
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. The flag is propagated as follows: renesas_sdhi_of_data::capabilities2 -> tmio_mmc_data::capabilities2 -> mmc_host::caps2 Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and TMIO_MMC_WRPROTECT_DISABLE at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: sdhci-iproc: Disable preset values for BCM2835Stefan Wahren1-0/+1
According to the BCM2835 datasheet there are no preset value registers. This wasn't an issue before, because we didn't propagate 1.8V support. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sh_mmcif: remove some cruftWolfram Sang1-8/+0
The TODO section from 2010 is obsolete. We have DMA and PM meanwhile and we always want to handle errors better, if possible. Also DRIVER_VERSION is not used anymore these days. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci_omap: Fix sdhci-omap quirksKishon Vijay Abraham I1-2/+2
Add SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk as setting preset values loads incorrect CLKD values (for UHS modes). Remove SDHCI_QUIRK2_NO_1_8_V quirk as sdhci-omap now supports UHS modes. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci_omap: Add support to set IODELAY valuesKishon Vijay Abraham I1-0/+148
The data manual of J6/J6 Eco recommends to set different IODELAY values depending on the mode in which the MMC/SD is enumerated in order to ensure IO timings are met. Add support to set the IODELAY values depending on the various MMC modes using the pinctrl APIs. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-omap: Workaround for Errata i802Kishon Vijay Abraham I1-0/+13
Errata i802 in AM572x Sitara Processors Silicon Revision 2.0, 1.1 (SPRZ429K July 2014–Revised March 2017 [1]) mentions DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure and it has to be disabled during the tuning procedure Implement workaround for Errata i802 here.. [1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdf Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-omap: Add tuning supportKishon Vijay Abraham I1-0/+130
MMC tuning procedure is required to support SD card UHS1-SDR104 mode and EMMC HS200 mode. SDR104/HS200 DLL Tuning Procedure for AM572x platform is mentioned in Figure 25-51. SDR104/HS200 DLL Tuning Procedure of AM572x Sitara Processors Silicon Revision 2.0, 1.1 TRM (SPRUHZ6I - October 2014–Revised April 2017 [1]). The tuning function sdhci_omap_execute_tuning() will only be called by the MMC/SD core if the corresponding speed modes are supported by the OMAP silicon which is set in the mmc host "caps" field. [1] -> http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-omap: Add custom set_uhs_signaling sdhci_host opsKishon Vijay Abraham I1-1/+22
UHS-1 DDR50 and MMC DDR52 mode require DDR bit to be set in the configuration register (MMCHS_CON). Add sdhci-omap specific set_uhs_signaling ops to set this bit. Also while setting the UHSMS bit, clock should be disabled. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-omap: Add card_busy host opsKishon Vijay Abraham I1-0/+52
Add card_busy host ops in sdhci_omap to check card busy status. The voltage switching sequence for AM572x platform is mentioned in Figure 25-48. eMMC/SD/SDIO Power Switching Procedure of AM572x Sitara Processors Silicon Revision 2.0, 1.1 TRM (SPRUHZ6I - October 2014–Revised April 2017 [1]). In the voltage switching sequence, CLKEXTFREE bit in MMCHS_CON should also be set after switching to 1.8v which is also taken care in the card_busy ops. [1] -> http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-omap: Update 'power_mode' outside sdhci_omap_init_74_clocksKishon Vijay Abraham I1-2/+8
Updating 'power_mode' in sdhci_omap_init_74_clocks results in 'power_mode' never updated to MMC_POWER_OFF during card removal. This results in initialization sequence not sent to the card during re-insertion. Fix it here by adding sdhci_omap_set_power_mode to update power_mode. This function can also be used later to perform operations that are specific to a power mode (e.g, disable tuning during power off). Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-02-27mmc: dw_mmc: Avoid accessing registers in runtime suspended stateShawn Lin1-0/+4
cat /sys/kernel/debug/mmc0/regs will hang up the system since it's in runtime suspended state, so the genpd and biu_clk is off. This patch fixes this problem by calling pm_runtime_get_sync to wake it up before reading the registers. Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>