aboutsummaryrefslogtreecommitdiff
path: root/drivers/mmc
AgeCommit message (Collapse)AuthorFilesLines
2021-10-28Merge branch 'fixes' into nextUlf Hansson1-19/+19
2021-10-28mmc: mediatek: Move cqhci init behind ungate clockWenbin Mei1-19/+19
We must enable clock before cqhci init, because crypto needs read information from CQHCI registers, otherwise, it will hang in MediaTek mmc host controller. Signed-off-by: Wenbin Mei <[email protected]> Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support") Cc: [email protected] Acked-by: Chaotian Jing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-28mmc: dw_mmc: exynos: Fix spelling mistake "candiates" -> candidatesColin Ian King1-10/+10
There are several spelling mistakes in variable names and in a dev_warn message. Fix these. Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-26mmc: sdhci-esdhc-imx: add NXP S32G2 supportChester Lin1-2/+15
Support the SDHCI controller found on NXP S32G2 platform. The new flag ESDHC_FLAG_SKIP_ERR004536 is used because the hardware erratum bit is not applicable for S32G2. Signed-off-by: Chester Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-26Merge branch 'fixes' into nextUlf Hansson3-9/+26
2021-10-26mmc: cqhci: clear HALT state after CQE enableWenbin Mei1-0/+3
While mmc0 enter suspend state, we need halt CQE to send legacy cmd(flush cache) and disable cqe, for resume back, we enable CQE and not clear HALT state. In this case MediaTek mmc host controller will keep the value for HALT state after CQE disable/enable flow, so the next CQE transfer after resume will be timeout due to CQE is in HALT state, the log as below: <4>.(4)[318:kworker/4:1H]mmc0: cqhci: timeout for tag 2 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: ============ CQHCI REGISTER DUMP =========== <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Caps: 0x100020b6 | Version: 0x00000510 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Config: 0x00001103 | Control: 0x00000001 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: TDL base: 0xfd05f000 | TDL up32: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Doorbell: 0x8000203c | TCN: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Task clr: 0x00000000 | SSC1: 0x00001000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQP: 0x00000000 | CRNQDUN: 0x00000000 <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQIS: 0x00000000 | CRNQIE: 0x00000000 This change check HALT state after CQE enable, if CQE is in HALT state, we will clear it. Signed-off-by: Wenbin Mei <[email protected]> Cc: [email protected] Acked-by: Adrian Hunter <[email protected]> Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-26mmc: vub300: fix control-message timeoutsJohan Hovold1-9/+9
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: [email protected] # 3.0 Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-26mmc: dw_mmc: exynos: fix the finding clock sample valueJaehoon Chung1-0/+14
Even though there are candiates value if can't find best value, it's returned -EIO. It's not proper behavior. If there is not best value, use a first candiate value to work eMMC. Signed-off-by: Jaehoon Chung <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Tested-by: Christian Hewitt <[email protected]> Cc: [email protected] Fixes: c537a1c5ff63 ("mmc: dw_mmc: exynos: add variable delay tuning sequence") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-21mmc: dw_mmc: Drop use of ->init_card() callbackUlf Hansson1-22/+17
For dw_mmc, the ->init_card() callback is being used to turn on/off automatic internal clock gating for powersave, which is needed to properly support SDIO irqs on DAT1. However, using the ->init_card() comes with a drawback in this case, as it means that the powersave feature becomes disabled, no matter whether the SDIO irqs becomes turned on or not. To improve the behaviour, let's change into using the ->enable_sdio_irq() callback instead. This works fine, because dw_mmc uses sdio_signal_irq() to signal the irqs, thus the ->enable_sdio_irq() is never executed from within atomic context. Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-21mmc: sdhci-omap: Fix build if CONFIG_PM_SLEEP is not setTony Lindgren1-3/+4
Commit f433e8aac6b9 ("mmc: sdhci-omap: Implement PM runtime functions") combined the use of runtime PM and system suspend functions but left the ifdef CONFIG_PM_SLEEP in place causing undeclared identifier error for sdhci_omap_runtime_suspend if CONFIG_PM_SLEEP is not enabled. Let's fix the error by removing ifdef CONFIG_PM_SLEEP and tagging the reset of the PM related functions with __maybe_unused. Let's also remove the forward declaration for sdhci_omap_context_save(), that was accidentally left from an earlier version and is no longer used. Reported-by: kernel test robot <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> [Ulf: Rebased and fixed build error] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-21mmc: sdhci-omap: Remove forward declaration of sdhci_omap_context_save()Geert Uytterhoeven1-2/+0
If CONFIG_PM_SLEEP=n: drivers/mmc/host/sdhci-omap.c:1213:13: error: ‘sdhci_omap_context_save’ declared ‘static’ but never defined [-Werror=unused-function] 1213 | static void sdhci_omap_context_save(struct sdhci_omap_host *omap_host); | ^~~~~~~~~~~~~~~~~~~~~~~ The referenced commit added an unrelated forward declaration of sdhci_omap_context_save(), which is unneeded in general, and unused when CONFIG_PM_SLEEP=n. Fixes: f433e8aac6b94218 ("mmc: sdhci-omap: Implement PM runtime functions") Reported-by: [email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-21blk-crypto: rename blk_keyslot_manager to blk_crypto_profileEric Biggers2-19/+23
blk_keyslot_manager is misnamed because it doesn't necessarily manage keyslots. It actually does several different things: - Contains the crypto capabilities of the device. - Provides functions to control the inline encryption hardware. Originally these were just for programming/evicting keyslots; however, new functionality (hardware-wrapped keys) will require new functions here which are unrelated to keyslots. Moreover, device-mapper devices already (ab)use "keyslot_evict" to pass key eviction requests to their underlying devices even though device-mapper devices don't have any keyslots themselves (so it really should be "evict_key", not "keyslot_evict"). - Sometimes (but not always!) it manages keyslots. Originally it always did, but device-mapper devices don't have keyslots themselves, so they use a "passthrough keyslot manager" which doesn't actually manage keyslots. This hack works, but the terminology is unnatural. Also, some hardware doesn't have keyslots and thus also uses a "passthrough keyslot manager" (support for such hardware is yet to be upstreamed, but it will happen eventually). Let's stop having keyslot managers which don't actually manage keyslots. Instead, rename blk_keyslot_manager to blk_crypto_profile. This is a fairly big change, since for consistency it also has to update keyslot manager-related function names, variable names, and comments -- not just the actual struct name. However it's still a fairly straightforward change, as it doesn't change any actual functionality. Acked-by: Ulf Hansson <[email protected]> # For MMC Reviewed-by: Mike Snitzer <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-10-21blk-crypto: rename keyslot-manager files to blk-crypto-profileEric Biggers1-1/+1
In preparation for renaming struct blk_keyslot_manager to struct blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c source files. Renaming these files separately before making a lot of changes to their contents makes it easier for git to understand that they were renamed. Acked-by: Ulf Hansson <[email protected]> # For MMC Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Mike Snitzer <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-10-19mmc: mxs-mmc: disable regulator on error and in the remove functionChristophe JAILLET1-0/+10
The 'reg_vmmc' regulator is enabled in the probe. It is never disabled. Neither in the error handling path of the probe nor in the remove function. Register a devm_action to disable it when needed. Fixes: 4dc5a79f1350 ("mmc: mxs-mmc: enable regulator for mmc slot") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/4aadb3c97835f7b80f00819c3d549e6130384e67.1634365151.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-omap: Configure optional wakeirqTony Lindgren1-0/+24
Configure optional wakeirq. This may be optionally configured for SDIO dat1 pin for wake-up events for SoCs that support deeper idle states. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PMTony Lindgren1-0/+3
Allow powering off SDIO cards and enable runtime PM for eMMC/SD card devices. Without this, SDIO WLAN devices will not idle. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-omap: Implement PM runtime functionsTony Lindgren1-17/+31
Implement PM runtime functions and enable autosuspend. Note that we save context in probe to avoid restoring invalid context on the first resume. For system suspend, we have the new PM runtime functions do most of the work. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-omap: Add omap_offset to support omap3 and earlierTony Lindgren1-16/+45
The omap specific registers are at offset 0x100 from base for omap4 and later, and for omap3 and earlier they are at offset 0. Let's handle also the earlier SoCs by adding omap_offset. Note that eventually we should just move to using standard sdhci register access for the sdhci range with new offsets starting at 0x100. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-omap: Handle voltages to add support omap4Tony Lindgren1-28/+96
In order to start deprecating the custom omap_hsmmc.c in favor of the generic sdhci-omap driver, we need to add support for voltages for earlier SoCs. The PBIAS regulator on omap4 and earlier only supports nominal values of 1.8V and 3.0V, while omap5 and later support nominal values of 1.8V and 3.3V IO voltage. This gets omap4/5 working with sdhci-omap driver. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19Merge branch 'fixes' into nextUlf Hansson2-1/+17
2021-10-19mmc: winbond: don't build on M68KRandy Dunlap1-1/+1
The Winbond MMC driver fails to build on ARCH=m68k so prevent that build config. Silences these build errors: ../drivers/mmc/host/wbsd.c: In function 'wbsd_request_end': ../drivers/mmc/host/wbsd.c:212:28: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration] 212 | dmaflags = claim_dma_lock(); ../drivers/mmc/host/wbsd.c:215:17: error: implicit declaration of function 'release_dma_lock'; did you mean 'release_task'? [-Werror=implicit-function-declaration] 215 | release_dma_lock(dmaflags); Signed-off-by: Randy Dunlap <[email protected]> Cc: Pierre Ossman <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning ↵Haibo Chen1-0/+16
circuit To reset standard tuning circuit completely, after clear ESDHC_MIX_CTRL_EXE_TUNE, also need to clear bit buffer_read_ready, this operation will finally clear the USDHC IP internal logic flag execute_tuning_with_clr_buf, make sure the following normal data transfer will not be impacted by standard tuning logic used before. Find this issue when do quick SD card insert/remove stress test. During standard tuning prodedure, if remove SD card, USDHC standard tuning logic can't clear the internal flag execute_tuning_with_clr_buf. Next time when insert SD card, all data related commands can't get any data related interrupts, include data transfer complete interrupt, data timeout interrupt, data CRC interrupt, data end bit interrupt. Always trigger software timeout issue. Even reset the USDHC through bits in register SYS_CTRL (0x2C, bit28 reset tuning, bit26 reset data, bit 25 reset command, bit 24 reset all) can't recover this. From the user's point of view, USDHC stuck, SD can't be recognized any more. Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card") Signed-off-by: Haibo Chen <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-pci: Remove dead code (rst_n_gpio et al)Andy Shevchenko2-29/+0
There is no user of this member. Remove the dead code for good. The removal is dependent on the previous removal of the struct sdhci_pci_data. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-pci: Remove dead code (cd_gpio, cd_irq et al)Andy Shevchenko2-77/+1
The last user of this struct gone couple of releases ago. Remove the dead code for good and encourage people to use MMC core functionality for that. The removal is dependent on the previous removal of the struct sdhci_pci_data. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci-pci: Remove dead code (struct sdhci_pci_data et al)Andy Shevchenko4-35/+4
The last user of this struct gone a couple of releases ago. Besides that there were not so many users of this API for more than 10 years: 1/ The one is Intel Merrifield, that had been added 2016-08-31 by the commit 3976b0380b31 ("x86/platform/intel-mid: Enable SD card detection on Merrifield") and removed 2021-02-11 by the commit 4590d98f5a4f ("sfi: Remove framework for deprecated firmware"). 2/ The other is Intel Sunrisepoint related, that had been added 2015-02-06 by the commit e1bfad6d936d ("mmc: sdhci-pci: Add support for drive strength selection for SPT") and removed 2017-03-20 by the commit 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices"). Effectively this is a revert of the commit 52c506f0bc72 ("mmc: sdhci-pci: add platform data"). Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci: Remove unused prototype declaration in the headerAndy Shevchenko1-1/+0
sdhci_card_detect() is not defined anywhere. Remove it. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-19mmc: sdhci: Deduplicate sdhci_get_cd_nogpio()Andy Shevchenko4-31/+21
The analogue of the sdhci_get_cd_nogpio() is used in the sdhci-pci-core and sdhci-acpi modules. Deduplicate it by moving to sdhci and exporting. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-18block: move struct request to blk-mq.hChristoph Hellwig1-0/+1
struct request is only used by blk-mq drivers, so move it and all related declarations to blk-mq.h. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-10-14mmc: moxart: Fix null pointer dereference on pointer hostColin Ian King1-6/+7
There are several error return paths that dereference the null pointer host because the pointer has not yet been set to a valid value. Fix this by adding a new out_mmc label and exiting via this label to avoid the host clean up and hence the null pointer dereference. Addresses-Coverity: ("Explicit null dereference") Fixes: 8105c2abbf36 ("mmc: moxart: Fix reference count leaks in moxart_probe") Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-14Merge branch 'fixes' into nextUlf Hansson1-5/+24
2021-10-14mmc: sdhci-pci: Read card detect from ACPI for Intel MerrifieldAndy Shevchenko1-5/+24
Intel Merrifield platform had been converted to use ACPI enumeration. However, the driver missed an update to retrieve card detect GPIO. Fix it here. Unfortunately we can't rely on CD GPIO state because there are two different PCB designs in the wild that are using the opposite card detection sense and there is no way to distinguish those platforms, that's why ignore CD GPIO completely and use it only as an event. Fixes: 4590d98f5a4f ("sfi: Remove framework for deprecated firmware") BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135 Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: moxart: Fix reference count leaks in moxart_probeXin Xiong1-2/+14
The issue happens in several error handling paths on two refcounted object related to the object "host" (dma_chan_rx, dma_chan_tx). In these paths, the function forgets to decrement one or both objects' reference count increased earlier by dma_request_chan(), causing reference count leaks. Fix it by balancing the refcounts of both objects in some error handling paths. In correspondence with the changes in moxart_probe(), IS_ERR() is replaced with IS_ERR_OR_NULL() in moxart_remove() as well. Signed-off-by: Xin Xiong <[email protected]> Signed-off-by: Xiyu Yang <[email protected]> Signed-off-by: Xin Tan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12Merge branch 'fixes' into nextUlf Hansson1-0/+6
2021-10-12mmc: slot-gpio: Update default label when no con_id providedAndy Shevchenko1-0/+8
Currently default label of GPIO is assigned to the device name, when no con_id provided. Instead, let's update it to reflect what it's about (use already prepared template). Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: slot-gpio: Refactor mmc_gpio_alloc()Andy Shevchenko1-17/+17
Refactor mmc_gpio_alloc() to drop unneeded indentation level and double condition. This increases readability of the code. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-sprd: Wait until DLL locked after being configuredZhenxiong Lai1-0/+13
According to the specification, DLL status has to be locked before using it. Signed-off-by: Zhenxiong Lai <[email protected]> Signed-off-by: Chunyan Zhang <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-pci-o2micro: Fix spelling mistake "unsupport" -> "unsupported"Colin Ian King1-1/+1
There is a spelling mistake in a pr_info message. Fix it. Also put msi in capital letters. Signed-off-by: Colin Ian King <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-s3c: Describe driver in KConfigKrzysztof Kozlowski1-3/+5
Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci: Return true only when timeout exceeds capacity of the HW timerBean Huo1-12/+9
Clean up sdhci_calc_timeout() a bit, and let it set too_big to be true only when the timeout value required by the eMMC device exceeds the capability of the host hardware timer. Signed-off-by: Bean Huo <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: mmci: Add small comment about reset threadLinus Walleij1-0/+4
Put a small comment before assigning IRQ_WAKE_THREAD telling us what is going on. Cc: Russell King <[email protected]> Cc: Yann Gautier <[email protected]> Cc: Ludovic Barre <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-omap: Check MMCHS_HL_HWINFO register for ADMATony Lindgren1-2/+22
ADMA is only available on controller instances that are connected to the L3 interconnect and are bus mastering capable. As the MMCHS_HL_HWINFO is in the module registers before omap registers and sdhci registers, and the omap registers and sdhci registers can be at different offsets depending on the SoC, let's read MMCHS_HL_HWINFO directly. Let's also switch to using device_property_present() while at it. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-omap: Parse legacy ti,non-removable propertyTony Lindgren1-0/+5
We need to support the legacy ti,non-removable property too. Let's warn about the legacy property and mark the device as non-removable. Naturally all the mainline kernel devicetree files will get updated to use the standard non-removable property with the sdhci-omap conversion. But we also have folks updating their kernels with custom devicetree files that we need to consider. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-omap: Restore sysconfig after resetTony Lindgren1-1/+13
The sysconfig register is managed in a generic way by PM runtime for us by the interconnect target module layer code. SDHCI_RESET_ALL also resets the target module configuration, so we need to restore sysconfig after reset. Note that there is no need to save and restore sysconfig during PM runtime, the PM runtime layer will do that for us. Not sure if this issue is a problem with the current configurations, I noticed the issue while adding support for older TI SoCs and testing with wlcore SDIO wlan device. Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-omap: Fix context restoreTony Lindgren1-1/+14
We need to restore context in a specified order with HCTL set in two phases. This is similar to what omap_hsmmc_context_restore() is doing. Otherwise SDIO can stop working on resume. And for PM runtime and SDIO cards, we need to also save SYSCTL, IE and ISE. This should not be a problem currently, and these patches can be applied whenever suitable. Fixes: ee0f309263a6 ("mmc: sdhci-omap: Add Support for Suspend/Resume") Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-omap: Fix NULL pointer exception if regulator is not configuredTony Lindgren1-1/+2
If sdhci-omap is configured for an unused device instance and the device is not set as disabled, we can get a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 00000045 ... (regulator_set_voltage) from [<c07d7008>] (mmc_regulator_set_ocr+0x44/0xd0) (mmc_regulator_set_ocr) from [<c07e2d80>] (sdhci_set_ios+0xa4/0x490) (sdhci_set_ios) from [<c07ea690>] (sdhci_omap_set_ios+0x124/0x160) (sdhci_omap_set_ios) from [<c07c8e94>] (mmc_power_up.part.0+0x3c/0x154) (mmc_power_up.part.0) from [<c07c9d20>] (mmc_start_host+0x88/0x9c) (mmc_start_host) from [<c07cad34>] (mmc_add_host+0x58/0x7c) (mmc_add_host) from [<c07e2574>] (__sdhci_add_host+0xf0/0x22c) (__sdhci_add_host) from [<c07eaf68>] (sdhci_omap_probe+0x318/0x72c) (sdhci_omap_probe) from [<c06a39d8>] (platform_probe+0x58/0xb8) AFAIK we are not seeing this with the devices configured in the mainline kernel but this can cause issues for folks bringing up their boards. Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver") Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: mtk-sd: Add HS400 online tuning supportWenbin Mei1-2/+77
According to JEDEC Spec, there is no need to do tuning under HS400 mode since the Rx signal is aligned with the DS signal. However, MediaTek's IC need set its "DS delay" internally to ensure it can latch Rx signal correctly. In previous version, We provide an "hs400-ds-delay" in device tree to cover different chipset/PCB design, and it works fine in most cases. But, with the development of process technology and the big VCore voltage scale range(may have 0.7V/0.6V/0.55V), it is difficult to find a suitable "hs400-ds-delay" to cover all of IC corner cases(SSSS/TTTT/FFFF). So that We must have the ability to do hs400 online tuning. Signed-off-by: Wenbin Mei <[email protected]> Reviewed-by: Chaotian Jing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: core: Add host specific tuning support for eMMC HS400 modeWenbin Mei2-1/+8
This adds a ->execute_hs400_tuning() host callback to enable optional support for host specific tuning for eMMC HS400 mode. Additionally, share mmc_get_ext_csd() through the public host headerfile, to allow it to be used by the host drivers, which is needed to support the HS400 tuning. Signed-off-by: Wenbin Mei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: sdhci-s3c: drop unneeded MODULE_ALIASKrzysztof Kozlowski1-1/+0
The MODULE_DEVICE_TABLE already creates proper alias for platform driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12dt-bindings: mmc: update mmc-card.yaml referenceMauro Carvalho Chehab1-1/+1
The recent change ("dt-bindings: mmc: Convert MMC Card binding to a schema") renamed: Documentation/devicetree/bindings/mmc/mmc-card.txt to: Documentation/devicetree/bindings/mmc/mmc-card.yaml. Let's update its cross-reference accordingly. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/820bb7a1d7e0e51cbea72c9bee6bce806427d1f3.1631785820.git.mchehab+huawei@kernel.org Signed-off-by: Ulf Hansson <[email protected]>
2021-10-12mmc: dw_mmc: Dont wait for DRTO on Write RSP errorChristian Löhle1-1/+2
Only wait for DRTO on reads, otherwise the driver hangs. The driver prevents sending CMD12 on response errors like CRCs. According to the comment this is because some cards have problems with this during the UHS tuning sequence. Unfortunately this workaround currently also applies for any command with data. On reads this will set the drto timer, which then triggers after a while. On writes this will not set any timer and the tasklet will not be scheduled again. I cannot test for the UHS workarounds need, but even if so, it should at most apply to reads. I have observed many hangs when CMD25 response contained a CRC error. This patch fixes this without touching the actual UHS tuning workaround. Signed-off-by: Christian Loehle <[email protected]> Reviewed-by: Jaehoon Chung <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.