kernel/linux.git/drivers/mmc/host, branch v4.4.235

mmc: sdhci: Fix regression setting power on Trats2 board

2020-05-10T08:26:07+00:00

commit 1dceb0415aa0c6bc11dacdab47c9ef83a3604166 upstream. Several commits relating to setting power have been introducing problems by putting driver-specific rules into generic SDHCI code. Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via external regulator") on Trats2 board there are warnings for invalid VDD value (2.8V): [ 3.119656] ------------[ cut here ]------------ [ 3.119666] WARNING: CPU: 3 PID: 90 at ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0 [ 3.119669] mmc0: Invalid vdd 0x10 [ 3.119673] Modules linked in: [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W 4.5.0-next-20160324 #23 [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 3.119690] Workqueue: events_freezable mmc_rescan [ 3.119708] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 3.119719] [] (show_stack) from [] (dump_stack+0x88/0x9c) [ 3.119728] [] (dump_stack) from [] (__warn+0xe8/0x100) [ 3.119734] [] (__warn) from [] (warn_slowpath_fmt+0x38/0x48) [ 3.119740] [] (warn_slowpath_fmt) from [] (sdhci_do_set_ios+0x4cc/0x5e0) [ 3.119748] [] (sdhci_do_set_ios) from [] (sdhci_runtime_resume_host+0x60/0x114) [ 3.119758] [] (sdhci_runtime_resume_host) from [] (__rpm_callback+0x2c/0x60) [ 3.119767] [] (__rpm_callback) from [] (rpm_callback+0x20/0x80) [ 3.119773] [] (rpm_callback) from [] (rpm_resume+0x36c/0x558) [ 3.119780] [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) [ 3.119788] [] (__pm_runtime_resume) from [] (__mmc_claim_host+0x170/0x1b0) [ 3.119795] [] (__mmc_claim_host) from [] (mmc_rescan+0x54/0x348) [ 3.119807] [] (mmc_rescan) from [] (process_one_work+0x120/0x3f4) [ 3.119815] [] (process_one_work) from [] (worker_thread+0x38/0x554) [ 3.119823] [] (worker_thread) from [] (kthread+0xdc/0xf4) [ 3.119831] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 3.119834] ---[ end trace a22d652aa3276886 ]--- Fix by adding a 'set_power' callback and restoring the default behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via external regulator"). The desired behaviour of that commit is gotten by having sdhci-pxav3 provide its own set_power callback. Reported-by: Krzysztof Kozlowski Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...) Tested-by: Krzysztof Kozlowski Tested-by: Ludovic Desroches Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v4.5+ Reviewed-by: Jisheng Zhang Tested-by: Jisheng Zhang Tested-by: Jaehoon Chung Tested-by: Anand Moon Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: moxart: fix wait_for_completion_interruptible_timeout return variable type

2020-05-10T08:26:07+00:00

commit 41f469cac2663a41a7b0c84cb94e8f7024385ae4 upstream. wait_for_completion_timeout_interruptible returns long not unsigned long so dma_time, which is used exclusively here, is changed to long. Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by: Nicholas Mc Guire Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: rockchip: Set the drive phase properly

2020-05-10T08:26:07+00:00

commit d4aa908c7978f60557a799ca53b5ae4166fd8355 upstream. Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") we actually started setting this explicitly in the kernel, but that commit wasn't quite right and also wasn't quite enough. See for some details. Let's explicitly set this phase in dw_mmc. The comments inside this patch try to explain the situation quite throughly, but the high level overview of this is: Before this patch on rk3288 devices tested (after revert of the clock patch described above): * eMMC: 180 degrees * SDMMC/SDIO0/SDIO1: 90 degrees After this patch: * Use 90 degree phase offset usually. * Use 180 degree phase offset for MMC_DDR52, SDR104, HS200. That means we are _changing_ behavior for those devices in this way: * If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90 degrees (vs 180) but otherwise have no change. * For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at 90 degrees (vs 180). It seems fairly unlikely that building modern hardware is using an eMMC that isn't using DDR52 or HS200, of course. * For SDR104 cards we'll now run with 180 degree phase offset (vs 90). It's expected that 90 degree phase offset would have worked OK, but this gives us extra margin. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by: Douglas Anderson Reviewed-by: Shawn Lin Tested-by: Heiko Stuebner Tested-by: Enric Balletbo i Serra Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: restore behavior when setting VDD via external regulator

2020-05-10T08:26:06+00:00

commit 918f4cbd4340ddd1eb389cd8efa3b07ac74ec4c0 upstream. After commit 52221610dd84 ("mmc: sdhci: Improve external VDD regulator support"), for the VDD is supplied via external regulators, we ignore the code to convert a VDD voltage request into one of the standard SDHCI voltage levels, then program it in the SDHCI_POWER_CONTROL. This brings two issues: 1. SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk isn't handled properly any more. 2. What's more, once SDHCI_POWER_ON bit is set, some controllers such as the sdhci-pxav3 used in marvell berlin SoCs require the voltage levels programming in the SDHCI_POWER_CONTROL register, even the VDD is supplied by external regulator. So the host in marvell berlin SoCs still works fine after the commit. However, commit 3cbc6123a93d ("mmc: sdhci: Set SDHCI_POWER_ON with external vmmc") sets the SDHCI_POWER_ON bit, this would make the host in marvell berlin SoCs won't work any more with external vmmc. This patch restores the behavior when setting VDD through external regulator by moving the call of mmc_regulator_set_ocr() to the end of sdhci_set_power() function. After this patch, the sdcard on Marvell Berlin SoC boards work again. Signed-off-by: Jisheng Zhang Fixes: 52221610dd84 ("mmc: sdhci: Improve external VDD ...") Reviewed-by: Ludovic Desroches Tested-by: Ludovic Desroches Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: spi: Toggle SPI polarity, do not hardcode it

2020-02-14T21:29:55+00:00

commit af3ed119329cf9690598c5a562d95dfd128e91d6 upstream. The code in mmc_spi_initsequence() tries to send a burst with high chipselect and for this reason hardcodes the device into SPI_CS_HIGH. This is not good because the SPI_CS_HIGH flag indicates logical "asserted" CS not always the physical level. In some cases the signal is inverted in the GPIO library and in that case SPI_CS_HIGH is already set, and enforcing SPI_CS_HIGH again will actually drive it low. Instead of hard-coding this, toggle the polarity so if the default is LOW it goes high to assert chipselect but if it is already high then toggle it low instead. Cc: Phil Elwell Reported-by: Mark Brown Signed-off-by: Linus Walleij Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20191204152749.12652-1-linus.walleij@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: fix minimum clock rate for v3 controller

2020-01-29T09:21:51+00:00

commit 2a187d03352086e300daa2044051db00044cd171 upstream. For SDHCIv3+ with programmable clock mode, minimal clock frequency is still base clock / max(divider). Minimal programmable clock frequency is always greater than minimal divided clock frequency. Without this patch, SDHCI uses out-of-spec initial frequency when multiplier is big enough: mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz [for 480 MHz source clock divided by 1024] The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode. Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode") Cc: # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: Signed-off-by: Michał Mirosław Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Update the tuning failed messages to pr_debug level

2020-01-04T12:34:38+00:00

[ Upstream commit 2c92dd20304f505b6ef43d206fff21bda8f1f0ae ] Tuning support in DDR50 speed mode was added in SD Specifications Part1 Physical Layer Specification v3.01. Its not possible to distinguish between v3.00 and v3.01 from the SCR and that is why since commit 4324f6de6d2e ("mmc: core: enable CMD19 tuning for DDR50 mode") tuning failures are ignored in DDR50 speed mode. Cards compatible with v3.00 don't respond to CMD19 in DDR50 and this error gets printed during enumeration and also if retune is triggered at any time during operation. Update the printk level to pr_debug so that these errors don't lead to false error reports. Signed-off-by: Faiz Abbas Cc: stable@vger.kernel.org # v4.4+ Link: https://lore.kernel.org/r/20191206114326.15856-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-esdhc: fix P2020 errata handling

2020-01-04T12:34:23+00:00

commit fe0acab448f68c3146235afe03fb932e242ec94c upstream. Two previous patches introduced below quirks for P2020 platforms. - SDHCI_QUIRK_RESET_AFTER_REQUEST - SDHCI_QUIRK_BROKEN_TIMEOUT_VAL The patches made a mistake to add them in quirks2 of sdhci_host structure, while they were defined for quirks. host->quirks2 |= SDHCI_QUIRK_RESET_AFTER_REQUEST; host->quirks2 |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; This patch is to fix them. host->quirks |= SDHCI_QUIRK_RESET_AFTER_REQUEST; host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; Fixes: 05cb6b2a66fa ("mmc: sdhci-of-esdhc: add erratum eSDHC-A001 and A-008358 support") Fixes: a46e42712596 ("mmc: sdhci-of-esdhc: add erratum eSDHC5 support") Signed-off-by: Yangbo Lu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191216031842.40068-1-yangbo.lu@nxp.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

Revert "mmc: sdhci: Fix incorrect switch to HS mode"

2020-01-04T12:34:17+00:00

commit 07bcc411567cb96f9d1fc84fff8d387118a2920d upstream. This reverts commit c894e33ddc1910e14d6f2a2016f60ab613fd8b37. This commit aims to treat SD High speed and SDR25 as the same while setting UHS Timings in HOST_CONTROL2 which leads to failures with some SD cards in AM65x. Revert this commit. The issue this commit was trying to fix can be implemented in a platform specific callback instead of common sdhci code. Cc: Signed-off-by: Faiz Abbas Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20191128110422.25917-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: mediatek: fix cannot receive new request when msdc_cmd_is_ready fail

2019-11-28T17:25:38+00:00

[ Upstream commit f38a9774ddde9d79b3487dd888edd8b8623552af ] when msdc_cmd_is_ready return fail, the req_timeout work has not been inited and cancel_delayed_work() will return false, then, the request return directly and never call mmc_request_done(). so need call mod_delayed_work() before msdc_cmd_is_ready() Signed-off-by: Chaotian Jing Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin