summaryrefslogtreecommitdiff
path: root/drivers/mmc
AgeCommit message (Collapse)Author
2017-12-20mmc: mediatek: Fixed bug where clock frequency could be set wrongyong mao
[ Upstream commit 40ceda09c8c84694c2ca6b00bcc6dc71e8e62d96 ] This patch can fix two issues: Issue 1: In previous code, div may be overflow when setting clock frequency as f_min. We can use DIV_ROUND_UP to fix this boundary related issue. Issue 2: In previous code, we can not set the correct clock frequency when div equals 0xff. Signed-off-by: Yong Mao <yong.mao@mediatek.com> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-09mmc: sdhci-msm: fix issue with power irqSubhash Jadavani
[ Upstream commit c7ccee224d2d551f712752c4a16947f6529d6506 ] SDCC controller reset (SW_RST) during probe may trigger power irq if previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we enable the power irq interrupt in GIC (by registering the interrupt handler), we need to ensure that any pending power irq interrupt status is acknowledged otherwise power irq interrupt handler would be fired prematurely. Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-05mmc: core: prepend 0x to OCR entry in sysfsBastian Stender
commit c892b0d81705c566f575e489efc3c50762db1bde upstream. The sysfs entry "ocr" was missing the 0x prefix to identify it as hex formatted. Fixes: 5fb06af7a33b ("mmc: core: Extend sysfs with OCR register") Signed-off-by: Bastian Stender <bst@pengutronix.de> [Ulf: Amended change to also cover SD-cards] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-05mmc: core: Do not leave the block driver in a suspended stateAdrian Hunter
commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream. The block driver must be resumed if the mmc bus fails to suspend the card. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-08mmc: s3cmci: include linux/interrupt.h for tasklet_structArnd Bergmann
[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq': drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration] While I haven't found out why this happened now and not earlier, the solution is obvious, we should include the header that defines the structure. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-12mmc: core: add driver strength selection when selecting hs400esChanho Min
commit fb458864d9a78cc433fec7979acbe4078c82d7a8 upstream. The driver strength selection is missed and required when selecting hs400es. So, It is added here. Fixes: 81ac2af65793ecf ("mmc: core: implement enhanced strobe support") Signed-off-by: Hankyung Yu <hankyung.yu@lge.com> Signed-off-by: Chanho Min <chanho.min@lge.com> Reviewed-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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-08mmc: sdio: fix alignment issue in struct sdio_funcHeiner Kallweit
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ] Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be used for DMA to be 8-byte-aligned. struct sdio_func has an embedded small DMA buffer not meeting this requirement. When testing switching to descriptor chain mode in meson-gx driver SDIO is broken therefore. Fix this by allocating the small DMA buffer separately as kmalloc ensures that the returned memory area is properly aligned for every basic data type. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Tested-by: Helmut Klein <hgkr.klein@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-16mmc: mmc: correct the logic for setting HS400ES signal voltageHaibo Chen
commit 92ddd95919466de5d34f3cb43635da9a7f9ab814 upstream. Change the default err value to -EINVAL, make sure the card only has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage setting when select hs400es mode. Fixes: commit 1720d3545b77 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11mmc: core: Use device_property_read instead of of_property_readDavid Woods
commit 73a47a9bb3e2c4a9c553c72456e63ab991b1a4d9 upstream. Using the device_property interfaces allows mmc drivers to work on platforms which run on either device tree or ACPI. Signed-off-by: David Woods <dwoods@mellanox.com> Reviewed-by: Chris Metcalf <cmetcalf@mellanox.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11mmc: dw_mmc: Use device_property_read instead of of_property_readDavid Woods
commit 852ff5fea9eb6a9799f1881d6df2cd69a9e6eed5 upstream. Using the device_property interfaces allows the dw_mmc driver to work on platforms which run on either device tree or ACPI. Signed-off-by: David Woods <dwoods@mellanox.com> Reviewed-by: Chris Metcalf <cmetcalf@mellanox.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11mmc: core: Fix access to HS400-ES devicesGuenter Roeck
commit 773dc118756b1f38766063e90e582016be868f09 upstream. HS400-ES devices fail to initialize with the following error messages. mmc1: power class selection to bus width 8 ddr 0 failed mmc1: error -110 whilst initialising MMC card This was seen on Samsung Chromebook Plus. Code analysis points to commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without high-speed mode"), which attempts to set the bus width for all but HS200 devices unconditionally. However, for HS400-ES, the bus width is already selected. Cc: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Douglas Anderson <dianders@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11mmc: sdhci-of-at91: force card detect value for non removable devicesLudovic Desroches
commit 7a1e3f143176e8ebdb2f5a9b3b47abc18b879d90 upstream. When the device is non removable, the card detect signal is often used for another purpose i.e. muxed to another SoC peripheral or used as a GPIO. It could lead to wrong behaviors depending the default value of this signal if not muxed to the SDHCI controller. Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC") Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07mmc: sdhci-iproc: suppress spurious interrupt with Multiblock readSrinath Mannam
commit f5f968f2371ccdebb8a365487649673c9af68d09 upstream. The stingray SDHCI hardware supports ACMD12 and automatically issues after multi block transfer completed. If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen on multi block read command with below error message: Got data interrupt 0x00000002 even though no data operation was in progress. This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACM12 support in SDHCI hardware and suppress spurious interrupt. Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden <scott.branden@broadcom.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-03Revert "mmc: sdhci-msm: Enable few quirks"Greg Kroah-Hartman
This reverts commit d84be51d1c1d3fa148a3abdeeb1455690df59e63 which is commit a0e3142869d29688de6f77be31aa7a401a4a88f1 upstream. It causes problems and would need other patches backported to resolve it, and it shouldn't have been applied to 4.9-stable. Reported-by: Georgi Djakov <georgi.djakov@linaro.org> Cc: Sahitya Tummala <stummala@codeaurora.org> Cc: Ritesh Harjani <riteshh@codeaurora.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-27mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 cardHaibo Chen
commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream. Currently for DDR50 card, it need tuning in default. We meet tuning fail issue for DDR50 card and some data CRC error when DDR50 sd card works. This is because the default pad I/O drive strength can't make sure DDR50 card work stable. So increase the pad I/O drive strength for DDR50 card, and use pins_100mhz. This fixes DDR50 card support for IMX since DDR50 tuning was enabled from commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50") Tested-and-reported-by: Tim Harvey <tharvey@gateworks.com> 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-12mmc: sdhci-of-esdhc: remove default broken-cd for ARMyangbo lu
[ Upstream commit e9acc77dd046b22c7ebf70e35f68968978445f8b ] Initially all QorIQ platforms were PowerPC architecture and they didn't support card detection except several platforms. The driver added the quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION as default and this made broken-cd property in dts node didn't work. Now QorIQ platform turns to ARM architecture and most of them could support card detection. However it's a large number of dts trees that need to be fixed with broken-cd if we remove the default SDHCI_QUIRK_BROKEN_CARD_DETECTION in driver. And the users don't want to see this. So this patch is to remove this default quirk just for ARM and keep it for PowerPC.(Note, QorIQ PowerPC platform only has big-endian eSDHC while QorIQ ARM platform has big-endian or little-endian eSDHC) This makes broken-cd property work again for ARM. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-12mmc: sdhci-msm: Enable few quirksRitesh Harjani
[ Upstream commit a0e3142869d29688de6f77be31aa7a401a4a88f1 ] sdhc-msm controller needs this SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN & SDHCI_QUIRK2_PRESET_VALUE_BROKEN to be set. Hence setting it. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08mmc: sdhci-of-at91: fix MMC_DDR_52 timing selectionLudovic Desroches
commit d0918764c17b94c30bbb2619929b1719ff52707a upstream. The controller has different timings for MMC_TIMING_UHS_DDR50 and MMC_TIMING_MMC_DDR52. Configuring the controller with SDHCI_CTRL_UHS_DDR50, when MMC_TIMING_MMC_DDR52 timings are requested, is not correct and can lead to unexpected behavior. Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08mmc: sdhci: Disable runtime pm when the sdio_irq is enabledHans de Goede
commit 923713b357455cfb9aca2cd3429cb0806a724ed2 upstream. SDIO cards may need clock to send the card interrupt to the host. On a cherrytrail tablet with a RTL8723BS wifi chip, without this patch pinging the tablet results in: PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data. 64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=78.6 ms 64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1760 ms 64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=753 ms 64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=3.88 ms 64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=795 ms 64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1841 ms 64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=810 ms 64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1860 ms 64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=812 ms 64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=48.6 ms Where as with this patch I get: PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data. 64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=3.96 ms 64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1.97 ms 64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=17.2 ms 64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=2.46 ms 64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=2.83 ms 64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1.40 ms 64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=2.10 ms 64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1.40 ms 64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=2.04 ms 64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=1.40 ms Cc: Dong Aisheng <b29396@freescale.com> Cc: Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-30mmc: sdhci-pci: Do not disable interrupts in sdhci_intel_set_powerAdrian Hunter
commit 027fb89e61054b4aedd962adb3e2003dec78a716 upstream. Disabling interrupts for even a millisecond can cause problems for some devices. That can happen when Intel host controllers wait for the present state to propagate. The spin lock is not necessary here. Anything that is racing with changes to the I/O state is already broken. The mmc core already provides synchronization via "claiming" the host. Although the spin lock probably should be removed from the code paths that lead to this point, such a patch would touch too much code to be suitable for stable trees. Consequently, for this patch, just drop the spin lock while waiting. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-30mmc: sdhci: Do not disable interrupts while waiting for clockAdrian Hunter
commit e2ebfb2142acefecc2496e71360f50d25726040b upstream. Disabling interrupts for even a millisecond can cause problems for some devices. That can happen when sdhci changes clock frequency because it waits for the clock to become stable under a spin lock. The spin lock is not necessary here. Anything that is racing with changes to the I/O state is already broken. The mmc core already provides synchronization via "claiming" the host. Although the spin lock probably should be removed from the code paths that lead to this point, such a patch would touch too much code to be suitable for stable trees. Consequently, for this patch, just drop the spin lock while waiting. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-30mmc: sdhci-of-arasan: fix incorrect timeout clockAnssi Hannula
commit 16681037e75ce08f2980ac5dbb03414429c7a55d upstream. sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 << (13 + divisor)). However, the divisor is not some Arasan-specific value, but instead is just the Data Timeout Counter Value from the SDHCI Timeout Control Register. Applying it here like this is wrong as the sdhci driver already takes that value into account when calculating timeouts, and in fact it *sets* that register value based on how long a timeout is wanted. Additionally, sdhci core interprets the .get_timeout_clock callback return value as if it were read from hardware registers, i.e. the unit should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit. This bit is set at least on the tested Zynq-7000 SoC. With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in too high a timeout clock rate being reported, causing the core to use longer-than-needed timeouts. Additionally, on a partitioned MMC (therefore having erase_group_def bit set) mmc_calc_max_discard() disables discard support as it looks like controller does not support the long timeouts needed for that. Do not apply the extra divisor and return the timeout clock in the expected unit. Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR eMMC card. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Fixes: e3ec3a3d11ad ("mmc: arasan: Add driver for Arasan SDHCI") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-30mmc: sdhci-of-at91: Support external regulatorsRomain Izard
commit 2ce0c7b65505e0d915e99389cced45b478dc935d upstream. The SDHCI controller in the SAMA5D2 chip requires a valid voltage set in the power control register, otherwise commands will fail with a timeout error. When using the regulator framework to specify the regulator used by the mmc device, the voltage is not configured, and it is not possible to use the connected device. Implement a custom 'set_power' function for this specific hardware, that configures the voltage in the register in all cases. Signed-off-by: Romain Izard <romain.izard.pro@gmail.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-30mmc: ushc: fix NULL-deref at probeJohan Hovold
commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver") Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-12mmc: sdhci-acpi: support deferred probeZhang Rui
commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream. With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns -EPROBE_DEFER if GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi driver should be probed again later in this case. This fixes an order issue when both GPIO and sdhci-acpi drivers are built as modules. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101 Tested-by: Jonas Aaberg <cja@gmx.net> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-23mmc: core: fix multi-bit bus width without high-speed modeAnssi Hannula
commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 upstream. Commit 577fb13199b1 ("mmc: rework selection of bus speed mode") refactored bus width selection code to mmc_select_bus_width(). However, it also altered the behavior to not call the selection code in non-high-speed modes anymore. This causes 1-bit mode to always be used when the high-speed mode is not enabled, even though 4-bit and 8-bit bus are valid bus widths in the backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed Modes in JEDEC 84-B50). This results in a significant regression in transfer speeds. Fix the code to allow 4-bit and 8-bit widths even without high-speed mode, as before. Tested with a Zynq-7000 PicoZed 7020 board. Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-09mmc: sdhci: Ignore unexpected CARD_INT interruptsGabriel Krisman Bertazi
commit 161e6d44a5e2d3f85365cb717d60e363171b39e6 upstream. One of our kernelCI boxes hanged at boot because a faulty eSDHC device was triggering spurious CARD_INT interrupts for SD cards, causing CMD52 reads, which are not allowed for SD devices. This adds a sanity check to the interruption path, preventing that illegal command from getting sent if the CARD_INT interruption should be disabled. This quirk allows that particular machine to resume boot despite the faulty hardware, instead of getting hung dealing with thousands of mishandled interrupts. Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-26mmc: mxs-mmc: Fix additional cycles after transmission stopStefan Wahren
commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 upstream. According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-26mmc: sdhci-acpi: Only powered up enabled acpi child devicesHans de Goede
commit e1d070c3793a2766122865a7c2142853b48808c5 upstream. Commit e5bbf30733f9 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") introduced code to powerup any acpi child nodes listed in the dstd. But some dstd-s list all possible devices used on some board variants, while reporting if the device is actually present and enabled in the status field of the device. So we end up calling the acpi _PS0 (power-on) method for devices which are not actually present. This does not always end well, e.g. on my cube iwork8 air tablet, this results in freezing the entire tablet as soon as the r8723bs module is loaded. This commit fixes this by checking the child device's status.present and status.enabled bits and only call acpi_device_fix_up_power() if both are set. Fixes: e5bbf30733f9 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") BugLink: https://github.com/hadess/rtl8723bs/issues/80 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12mmc: mmc_test: Uninitialized return valueDan Carpenter
commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream. We never set "ret" to RESULT_OK. Fixes: 9f9c4180f88d ("mmc: mmc_test: add test for non-blocking transfers") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-09mmc: sd: Meet alignment requirements for raw_ssr DMAPaul Burton
commit e85baa8868b016513c0f5738362402495b1a66a5 upstream. The mmc_read_ssr() function results in DMA to the raw_ssr member of struct mmc_card, which is not guaranteed to be cache line aligned & thus might not meet the requirements set out in Documentation/DMA-API.txt: Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Since the cache line size may not be known at compile time, the API will not enforce this requirement. Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). On some systems where DMA is non-coherent this can lead to us losing data that shares cache lines with the raw_ssr array. Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc will ensure the buffer is suitably aligned, allowing the DMA to be performed without any loss of data. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-09mmc: sdhci: Fix recovery from tuning timeoutAdrian Hunter
commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream. Clearing the tuning bits should reset the tuning circuit. However there is more to do. Reset the command and data lines for good measure, and then for eMMC ensure the card is not still trying to process a tuning command by sending a stop command. Note the JEDEC eMMC specification says the stop command (CMD12) can be used to stop a tuning command (CMD21) whereas the SD specification is silent on the subject with respect to the SD tuning command (CMD19). Considering that CMD12 is not a valid SDIO command, the stop command is sent only when the tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far which have been on eMMC. Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits after tuning failure") which is being reverted for v4.9+. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Dan O'Donovan <dan@emutex.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-09Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"Adrian Hunter
commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream. This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits after tuning failure"). A better fix is available, and it will be applied to older stable releases, so get this out of the way by reverting it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-21mmc: dw_mmc: fix the error handling for dma operationJaehoon Chung
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 <m.szyprowski@samsung.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: <stable@vger.kernel.org> # v4.3+ Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-18mmc: sdhci-of-esdhc: fixup PRESENT_STATE readMichael Walle
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 <michael@walle.cc> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()") Acked-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: <stable@vger.kernel.org> # v4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: mxs: Initialize the spinlock prior to using itFabio Estevam
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 <fabio.estevam@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: mmc: Use 500ms as the default generic CMD6 timeoutUlf Hansson
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: <stable@vger.kernel.org> # v4.8+ Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Linus Walleij <linus.walleij@linaro.org>
2016-11-07mmc: mmc_test: Fix "Commands during non-blocking write" testsAdrian Hunter
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 <adrian.hunter@intel.com> Tested-by: Ritesh Harjani <riteshh@codeaurora.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: sdhci: Fix missing enhanced strobe setting during runtime resumeAdrian Hunter
Restore enhanced strobe setting during runtime resume. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: sdhci: Reset cmd and data circuits after tuning failureAdrian Hunter
To prevent subsequent commands failing, ensure the cmd and data circuits are reset after a tuning timeout. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: sdhci: Fix unexpected data interrupt handlingAdrian Hunter
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 <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: sdhci: Fix CMD line reset interfering with ongoing data transferAdrian Hunter
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 <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-11-07mmc: dw_mmc: add the "reset" as name of reset controllerJaehoon Chung
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 <jh80.chung@samsung.com> Acked-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-27mmc: sdhci-msm: Fix error return code in sdhci_msm_probe()Wei Yongjun
Fix to return a negative error code from the platform_get_irq_byname() error handling case instead of 0, as done elsewhere in this function. Fixes: ad81d3871004 ("mmc: sdhci-msm: Add support for UHS cards") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-25mmc: dw_mmc-pltfm: fix the potential NULL pointer dereferenceJaehoon Chung
platform_get_resource can be returned the NULL pointer. Then regs->start should be referred to NULL Pointer. devm_ioremap_resource() checks whether res is NULL or not. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-17mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the ledUlf Hansson
Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device, must be done when it's runtime resumed. Currently this isn't case when changing the led, so let's fix this by adding a pm_runtime_get_sync() and a pm_runtime_put() around those operations. Reported-by: Ritesh Raj Sarraf <rrs@researchut.com> Tested-by: Ritesh Raj Sarraf <rrs@researchut.com> Cc: <stable@vger.kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-17mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unusedUlf Hansson
The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no SD card is inserted. This is wrong, as it could cause the device to remain runtime resumed when it's unused. Fix this behaviour. Tested-by: Ritesh Raj Sarraf <rrs@researchut.com> Cc: <stable@vger.kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-17mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted errorHaibo Chen
Potentially overflowing expression 1000000 * data->timeout_clks with type unsigned int is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type unsigned long long. To avoid overflow, cast 1000000U to type unsigned long long. Special thanks to Coverity. Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Cc: stable@vger.kernel.org # v3.15+ Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-10-13mmc: sdhci-esdhc-imx: Correct two register accessesAaron Brice
- The DMA error interrupt bit is in a different position as compared to the sdhci standard. This is accounted for in many cases, but not handled in the case of clearing the INT_STATUS register by writing a 1 to that location. - The HOST_CONTROL register is very different as compared to the sdhci standard. This is accounted for in the write case, but not when read back out (which it is in the sdhci code). Signed-off-by: Dave Russell <david.russell@datasoft.com> Signed-off-by: Aaron Brice <aaron.brice@datasoft.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>
2016-10-10mmc: sdhci-pci: Fix bus power failing to enable for some Intel controllersAdrian Hunter
Some Intel controllers (e.g. BXT) might fail to set bus power after a D3 -> D0 transition due to the present state not yet having propagated. Retry for up to 2 milliseconds. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit v1.2.3 (git 2.0.4) at 2025-01-29 08:11:09 +0000