From 77347eda64ed5c9383961d1de9165f9d0b7d8df6 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Thu, 24 Jun 2021 17:16:14 +0200 Subject: [PATCH 1/6] mmc: core: clear flags before allowing to retune It might be that something goes wrong during tuning so the MMC core will immediately trigger a retune. In our case it was: - we sent a tuning block - there was an error so we need to send an abort cmd to the eMMC - the abort cmd had a CRC error - retune was set by the MMC core This lead to a vicious circle causing a performance regression of 75%. So, clear retuning flags before we enable retuning to start with a known cleared state. Reported-by Yoshihiro Shimoda Suggested-by: Adrian Hunter Signed-off-by: Wolfram Sang Acked-by: Adrian Hunter Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson --- drivers/mmc/core/core.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index b039dcff17f8..95fedcf56e4a 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -937,11 +937,14 @@ int mmc_execute_tuning(struct mmc_card *card) err = host->ops->execute_tuning(host, opcode); - if (err) + if (err) { pr_err("%s: tuning execution failed: %d\n", mmc_hostname(host), err); - else + } else { + host->retune_now = 0; + host->need_retune = 0; mmc_retune_enable(host); + } return err; } From b2af322792d64d3748b9915cbcbd031dd035d7e2 Mon Sep 17 00:00:00 2001 From: Rashmi A Date: Thu, 3 Jun 2021 23:52:41 +0530 Subject: [PATCH 2/6] mmc: sdhci-of-arasan: Use clock-frequency property to update clk_xin If clock-frequency property is set and it is not the same as the current clock rate of clk_xin(base clock frequency), set clk_xin to use the provided clock rate. Signed-off-by: Rashmi A Reviewed-by: Adrian Hunter Tested-by: Sai Krishna Potthuri Link: https://lore.kernel.org/r/20210603182242.25733-2-rashmi.a@intel.com Signed-off-by: Ulf Hansson --- drivers/mmc/host/sdhci-of-arasan.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c index 839965f7c717..0e7c07ed9690 100644 --- a/drivers/mmc/host/sdhci-of-arasan.c +++ b/drivers/mmc/host/sdhci-of-arasan.c @@ -1542,6 +1542,8 @@ static int sdhci_arasan_probe(struct platform_device *pdev) } } + sdhci_get_of_property(pdev); + sdhci_arasan->clk_ahb = devm_clk_get(dev, "clk_ahb"); if (IS_ERR(sdhci_arasan->clk_ahb)) { ret = dev_err_probe(dev, PTR_ERR(sdhci_arasan->clk_ahb), @@ -1561,14 +1563,22 @@ static int sdhci_arasan_probe(struct platform_device *pdev) goto err_pltfm_free; } + /* If clock-frequency property is set, use the provided value */ + if (pltfm_host->clock && + pltfm_host->clock != clk_get_rate(clk_xin)) { + ret = clk_set_rate(clk_xin, pltfm_host->clock); + if (ret) { + dev_err(&pdev->dev, "Failed to set SD clock rate\n"); + goto clk_dis_ahb; + } + } + ret = clk_prepare_enable(clk_xin); if (ret) { dev_err(dev, "Unable to enable SD clock.\n"); goto clk_dis_ahb; } - sdhci_get_of_property(pdev); - if (of_property_read_bool(np, "xlnx,fails-without-test-cd")) sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST; From 2f2b73a29d2aabf5ad0150856c3e5cb6e04dcfc1 Mon Sep 17 00:00:00 2001 From: Rashmi A Date: Thu, 3 Jun 2021 23:52:42 +0530 Subject: [PATCH 3/6] phy: intel: Fix for warnings due to EMMC clock 175Mhz change in FIP Since the EMMC clock was changed from 200Mhz to 175Mhz in FIP, there were some warnings introduced, as the frequency values being checked was still wrt 200Mhz in code. Hence, the frequency checks are now updated based on the current 175Mhz EMMC clock changed in FIP. Spamming kernel log msg: "phy phy-20290000.mmc_phy.2: Unsupported rate: 43750000" Signed-off-by: Rashmi A Reviewed-by: Adrian Hunter Acked-By: Vinod Koul Link: https://lore.kernel.org/r/20210603182242.25733-3-rashmi.a@intel.com Signed-off-by: Ulf Hansson --- drivers/phy/intel/phy-intel-keembay-emmc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/phy/intel/phy-intel-keembay-emmc.c b/drivers/phy/intel/phy-intel-keembay-emmc.c index eb7c635ed89a..0eb11ac7c2e2 100644 --- a/drivers/phy/intel/phy-intel-keembay-emmc.c +++ b/drivers/phy/intel/phy-intel-keembay-emmc.c @@ -95,7 +95,8 @@ static int keembay_emmc_phy_power(struct phy *phy, bool on_off) else freqsel = 0x0; - if (mhz < 50 || mhz > 200) + /* Check for EMMC clock rate*/ + if (mhz > 175) dev_warn(&phy->dev, "Unsupported rate: %d MHz\n", mhz); /* From 49036ba889e346da6ebf2f741fe0b0ee49a11b08 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Fri, 11 Jun 2021 12:19:48 +0200 Subject: [PATCH 4/6] mmc: sdhci: Clear unused bounce buffer at DMA mmap error path When DMA-mapping of the bounce buffer fails, the driver tries to fall back, but it leaves the allocated host->bounce_buffer although its size is zero. Later on, the driver checks the use of bounce buffer with host->bounce_buffer pointer, and it tries to use the buffer incorrectly, resulting in Oops. This patch clears the release the unused buffer and clears the bounce_buffer pointer for addressing the problem. Acked-by: Adrian Hunter Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20210611101948.18972-1-tiwai@suse.de Signed-off-by: Ulf Hansson --- drivers/mmc/host/sdhci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 6aaf5c3ce34c..cf01b6f94d7f 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -4072,9 +4072,13 @@ static void sdhci_allocate_bounce_buffer(struct sdhci_host *host) bounce_size, DMA_BIDIRECTIONAL); ret = dma_mapping_error(mmc_dev(mmc), host->bounce_addr); - if (ret) + if (ret) { + devm_kfree(mmc_dev(mmc), host->bounce_buffer); + host->bounce_buffer = NULL; /* Again fall back to max_segs == 1 */ return; + } + host->bounce_buffer_size = bounce_size; /* Lie about this since we're bouncing */ From 2fee14ac97dc74f6a8525e69640c6972a4f36899 Mon Sep 17 00:00:00 2001 From: Wenbin Mei Date: Tue, 15 Jun 2021 11:00:33 +0800 Subject: [PATCH 5/6] dt-bindings: mmc: change compatiable string for MT8195 mmc host IP MT8195 mmc host IP is compatible with MT8183, and currently it shows: properties: compatible: oneOf: ... - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc which means the compatible string in the device tree would be: compatible = "mediatek,mt8192-mmc", "mediatek,mt8195-mmc", "mediatek,mt8183-mmc"; The bindings is wrong and that isn't the result we want. instead we want: properties: compatible: oneOf: ... - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8183-mmc - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc which would give us: compatible = "mediatek,mt8192-mmc", "mediatek,mt8183-mmc"; and compatible = "mediatek,mt8195-mmc", "mediatek,mt8183-mmc"; Fixes: eb9cb7227e5c (dt-bindings: mmc: Add compatible for Mediatek MT8195) Signed-off-by: Wenbin Mei Acked-by: Rob Herring Link: https://lore.kernel.org/r/1623726033-16073-2-git-send-email-wenbin.mei@mediatek.com Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 8648d48dbbfd..adaba903858a 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -31,6 +31,8 @@ properties: - const: mediatek,mt2701-mmc - items: - const: mediatek,mt8192-mmc + - const: mediatek,mt8183-mmc + - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc From d0244847f9fc5e20df8b7483c8a4717fe0432d38 Mon Sep 17 00:00:00 2001 From: Al Cooper Date: Thu, 24 Jun 2021 12:30:45 -0400 Subject: [PATCH 6/6] mmc: sdhci: Fix warning message when accessing RPMB in HS400 mode When an eMMC device is being run in HS400 mode, any access to the RPMB device will cause the error message "mmc1: Invalid UHS-I mode selected". This happens as a result of tuning being disabled before RPMB access and then re-enabled after the RPMB access is complete. When tuning is re-enabled, the system has to switch from HS400 to HS200 to do the tuning and then back to HS400. As part of sequence to switch from HS400 to HS200 the system is temporarily put into HS mode. When switching to HS mode, sdhci_get_preset_value() is called and does not have support for HS mode and prints the warning message and returns the preset for SDR12. The fix is to add support for MMC and SD HS modes to sdhci_get_preset_value(). This can be reproduced on any system running eMMC in HS400 mode (not HS400ES) by using the "mmc" utility to run the following command: "mmc rpmb read-counter /dev/mmcblk0rpmb". Signed-off-by: Al Cooper Acked-by: Adrian Hunter Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210624163045.33651-1-alcooperx@gmail.com Signed-off-by: Ulf Hansson --- drivers/mmc/host/sdhci.c | 4 ++++ drivers/mmc/host/sdhci.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index cf01b6f94d7f..aba6e10b8605 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1812,6 +1812,10 @@ static u16 sdhci_get_preset_value(struct sdhci_host *host) u16 preset = 0; switch (host->timing) { + case MMC_TIMING_MMC_HS: + case MMC_TIMING_SD_HS: + preset = sdhci_readw(host, SDHCI_PRESET_FOR_HIGH_SPEED); + break; case MMC_TIMING_UHS_SDR12: preset = sdhci_readw(host, SDHCI_PRESET_FOR_SDR12); break; diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index c35ed4be75b7..074dc182b184 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -255,6 +255,7 @@ /* 60-FB reserved */ +#define SDHCI_PRESET_FOR_HIGH_SPEED 0x64 #define SDHCI_PRESET_FOR_SDR12 0x66 #define SDHCI_PRESET_FOR_SDR25 0x68 #define SDHCI_PRESET_FOR_SDR50 0x6A