- 20 Jan, 2020 24 commits
-
-
Yangbo Lu authored
This patch is to fix a serious issue that clock is always disabled in esdhc_of_set_clock(). Fixes: 1b21a701 ("mmc: sdhci-of-esdhc: fix clock setting for different controller versions") Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Link: https://lore.kernel.org/r/20200120094835.28050-1-yangbo.lu@nxp.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Yangbo Lu authored
The standard SD controller uses two 16-bit registers for command sending. 0xC: Transfer Mode Register 0xE: Command Register But the eSDHC controller uses one 32-bit register instead. 0xC: XFERTYPE For Transfer Mode Register and Command Register writing, the eSDHC driver will store Transfer Mode Register value in a variable first. When Command Register writing happens, driver will directly write a 32-bit value into XFERTYPE register. But for Transfer Mode Register reading, driver just returns a actual value. This may cause issue for some read-modify-write operations. We should make both reading and write on that variable for Transfer Mode Register. Signed-off-by:
-
Al Cooper authored
When switching from any MMC speed mode that requires 1.8v (HS200, HS400 and HS400ES) to High Speed (HS) mode, the system ends up configured for SDR12 with a 50MHz clock which is an illegal mode. This happens because the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register is left set and when this bit is set, the speed mode is controlled by the SDHCI_CTRL_UHS field in the SDHCI_HOST_CONTROL2 register. The SDHCI_CTRL_UHS field will end up being set to 0 (SDR12) by sdhci_set_uhs_signaling() because there is no UHS mode being set. The fix is to change sdhci_set_uhs_signaling() to set the SDHCI_CTRL_UHS field to SDR25 (which is the same as HS) for any switch to HS mode. This was found on a new eMMC controller that does strict checking of the speed mode and the corresponding clock rate. It caused the switch to HS400 mode to fail because part of the sequence to switch to HS400 requires a switch from HS200 to HS before going to HS400. This issue was previously fixed by commit c894e33d ("mmc: sdhci: Fix incorrect switch to HS mode") and later removed by commit 07bcc411 ("Revert \"mmc: sdhci: Fix incorrect switch to HS mode\"") because it caused failures with some SD cards on AM65X systems. The fix will now be done in a platform specific callback instead of common sdhci code. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Suggested-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200113210706.11972-7-alcooperx@gmail.comSigned-off-by:
-
Al Cooper authored
The latest Arasan controller first used in the 7216 now supports CQE so enable this feature. Signed-off-by:
-
Al Cooper authored
Shutdown controller and disable it's clocks to insure max power savings in S5 on systems that leave power on. Signed-off-by:
-
Al Cooper authored
The new SCMI clock protocol driver does not get probed that early in boot. Brcmstb drivers typically have the following code when getting a clock: priv->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(priv->clk)) { dev_err(&pdev->dev, "Clock not found in Device Tree\n"); priv->clk = NULL; } This commit changes the driver to do what is below. priv->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(priv->clk)) { if (PTR_ERR(priv->clk) == -EPROBE_DEFER) return -EPROBE_DEFER; dev_err(&pdev->dev, "Clock not found in Device Tree\n"); priv->clk = NULL; } Signed-off-by: -
Al Cooper authored
The latest eMMC JEDEC specification version 5.1 added a new transfer mode, HS400 with enhanced strobe (HS400ES). This mode will be selected if both the host controller and eMMC device support it. The latest Arasan 5.1 controller in the 7216a0 supports this mode. The "Host Controller Specification" has not been updated so the controller register bit used to enable this mode is not specified and varies the with controller vendor. The Linux SDHCI driver supplies a callback for enabling HS400ES mode and that callback will be used to supply a routine that will set the proper bit in the Arasan Vendor register. Signed-off-by:
-
Al Cooper authored
Add 7216b0 with supports CQE, HS400, HS400-ES and SDR104. Signed-off-by:
-
Michał Mirosław authored
Currently MMC core disregards host->f_max during card initialization phase. Obey upper boundary for the clock frequency and skip faster speeds when they are above the limit. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/f471bceaf237d582d746bd289c4c4f3639cb7b45.1577962382.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
YueHaibing authored
platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. This is detected by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
Chunyan Zhang authored
Fix an issue reported by sparse, since mixed types of parameters are used on calling dmaengine_prep_slave_sg(). Fixes: 36e1da441fec (mmc: sdhci: add support for using external DMA devices) Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Chunyan Zhang <zhang.chunyan@linaro.org> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
-
Ulf Hansson authored
-
Michał Mirosław authored
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: c3ed3877 ("mmc: sdhci: add support for programmable clock mode") Cc: <stable@vger.kernel.org> # 4f6aa326: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: <stable@vger.kernel.org> Signed-off-by:
-
Faiz Abbas authored
Some omap controllers need software to monitor a 0->1->0 for software reset. Add a SDHCI_OMAP_SPECIAL_RESET flag to indicate this. Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
-
Faiz Abbas authored
Add support for new compatible for TI's am335x and am437x devices. Signed-off-by:
-
Faiz Abbas authored
Add binding for the TI's sdhci-omap controller present in am335x and am437x devices. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200116105154.7685-9-faiz_abbas@ti.comSigned-off-by:
-
Faiz Abbas authored
Disable data timeout interrupt during an erase operation. Signed-off-by:
-
Faiz Abbas authored
Refactor sdhci_set_timeout() such that platform drivers can do some functionality in a set_timeout() callback and then call __sdhci_set_timeout() to complete the operation. Signed-off-by:
-
Faiz Abbas authored
Export sdhci_set_timeout_irq() so that it is accessible from platform drivers. Signed-off-by:
-
Chunyan Zhang authored
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Fixes by Faiz Abbas <fazi_abbas@ti.com>: 1. Switch to DMA slave mode when using external DMA 2. Add offset to mapbase Signed-off-by:
-
Chunyan Zhang authored
Some standard SD host controllers can support both external dma controllers as well as ADMA/SDMA in which the SD host controller acts as DMA master. TI's omap controller is the case as an example. Currently the generic SDHCI code supports ADMA/SDMA integrated in the host controller but does not have any support for external DMA controllers implemented using dmaengine, meaning that custom code is needed for any systems that use an external DMA controller with SDHCI. Fixes by Faiz Abbas <faiz_abbas@ti.com>: 1. Map scatterlists before dmaengine_prep_slave_sg() 2. Use dma_async() functions inside of the send_command() path and call terminate_sync() in non-atomic context in case of an error. Signed-off-by:
-
Faiz Abbas authored
In preparation for adding external dma support, factor out data initialization, block info and mrq_done to their own functions. Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Acked-by:
-
Chunyan Zhang authored
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Add binding documentation for these external dma properties. Signed-off-by:
-
Anson Huang authored
Add compatible string for imx8mp Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Acked-by:
-
- 16 Jan, 2020 10 commits
-
-
Michał Mirosław authored
Commit 7ad2ed1d inadvertently mixed up a quirk flag's name and broke SDR50 tuning override. Use correct NVQUIRK_ name. Fixes: 7ad2ed1d ("mmc: tegra: enable UHS-I modes") Cc: <stable@vger.kernel.org> Acked-by:
Thierry Reding <treding@nvidia.com> Tested-by:
-
Michał Mirosław authored
sdhci_alloc_host() does its work not using managed infrastructure, so needs explicit free on error path. Add it where needed. Cc: <stable@vger.kernel.org> Fixes: bb5f8ea4 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC") Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by:
-
Ulf Hansson authored
-
Faiz Abbas authored
Command Queuing was enabled completely for J721e controllers which lead to partial enablement even for Am65x. Complete CQ implementation for AM65x by adding the irq callback. Fixes: f545702b ("mmc: sdhci_am654: Add Support for Command Queuing Engine to J721E") Cc: stable@vger.kernel.org Signed-off-by:
-
Faiz Abbas authored
The tuning data is leftover in the buffer after tuning. This can cause issues in future data commands, especially with CQHCI. Reset the command and data lines after tuning to continue from a clean state. Fixes: 41fd4cae ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Faiz Abbas authored
The MMC/SD controllers on am65x and j721e don't in fact detect the write protect line as inverted. No issues were detected because of this because the sdwp line is not connected on any of the evms. Fix this by removing the flag. Fixes: 1accbced ("mmc: sdhci_am654: Add Support for 4 bit IP on J721E") Cc: stable@vger.kernel.org Signed-off-by:
-
Yangbo Lu authored
This patch is to fix clock setting code for different controller versions. Two of HW changes after vendor version 2.2 are removing PEREN/HCKEN/IPGEN bits in system control register, and adding SD clock stable bit in present state register. This patch cleans up related code too. Signed-off-by:
-
Yangbo Lu authored
This patch is to fix operating in esdhc_reset() for different controller versions, and to add bus-width restoring after data reset for eSDHC (verdor version <= 2.2). Also add annotation for understanding. Signed-off-by:
-
Yangbo Lu authored
There is an official update for eSDHC tuning erratum A-008171. This patch is to implement the changes, - Affect all revisions of SoC. - Changes for tuning window checking. - Hardware hits a new condition that tuning succeeds although the eSDHC might not have tuned properly for type2 SoCs (soc_tuning_erratum_type2[] array in driver). So check tuning window after tuning succeeds. Signed-off-by:
-
Yangbo Lu authored
Convert to use a new function esdhc_tuning_window_ptr() to get tuning window start point and end point. Signed-off-by:
-
- 19 Dec, 2019 6 commits
-
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20191217122254.7103-1-peter.ujfalusi@ti.comSigned-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA if needed. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA if needed. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
-
