Re: [PATCH v2] mmc: mmci: manage MMC_CAP_NEED_RSP_BUSY for stm32 variant
From: Ulf Hansson <hidden>
Date: 2021-03-02 11:02:25
Also in:
linux-mmc, lkml
On Thu, 25 Feb 2021 at 15:55, Yann Gautier [off-list ref] wrote:
quoted hunk ↗ jump to hunk
To properly manage commands awaiting R1B responses, the capability MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for stm32 variant. The issue was seen on STM32MP157C-EV1 board, with an erase command, with secure erase argument, letting the card stuck, possibly waiting for 4 hours before timeout. Fixes: 94fe2580a2f3 ("mmc: core: Enable erase/discard/trim support for all mmc hosts") Signed-off-by: Yann Gautier <redacted> --- This is somehow a v2 for patch [1]. Changes: - Only apply MMC_CAP_NEED_RSP_BUSY to stm32 variant - Cap the used timeout written to MMCIDATATIMER (when using MMC_CAP_NEED_RSP_BUSY, cmd->busy_timeout may be greater than host->max_busy_timeout) [1] https://patchwork.kernel.org/project/linux-mmc/patch/20210204120547.15381-2-yann.gautier@foss.st.com/ drivers/mmc/host/mmci.c | 8 +++++++- drivers/mmc/host/mmci_stm32_sdmmc.c | 1 + 2 files changed, 8 insertions(+), 1 deletion(-)diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index 17dbc81c221e..89e0e9ccfb71 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c@@ -1242,7 +1242,13 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c) if (!cmd->busy_timeout) cmd->busy_timeout = 10 * MSEC_PER_SEC; - clks = (unsigned long long)cmd->busy_timeout * host->cclk; + if (host->mmc->caps & MMC_CAP_NEED_RSP_BUSY && + host->mmc->max_busy_timeout && + cmd->busy_timeout > host->mmc->max_busy_timeout)
We are already within "if (host->variant->busy_timeout ....", a few lines above, which means this can be simplified into: if (cmd->busy_timeout > host->mmc->max_busy_timeout)
quoted hunk ↗ jump to hunk
+ clks = (unsigned long long)host->mmc->max_busy_timeout * host->cclk; + else + clks = (unsigned long long)cmd->busy_timeout * host->cclk; + do_div(clks, MSEC_PER_SEC); writel_relaxed(clks, host->base + MMCIDATATIMER); }diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c index 51db30acf4dc..2ad577618324 100644 --- a/drivers/mmc/host/mmci_stm32_sdmmc.c +++ b/drivers/mmc/host/mmci_stm32_sdmmc.c@@ -522,6 +522,7 @@ void sdmmc_variant_init(struct mmci_host *host) host->ops = &sdmmc_variant_ops; host->pwr_reg = readl_relaxed(host->base + MMCIPOWER); + host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
To make it more clear that this is for variants having the ->busy_timeout flag set, I suggest to move this into mmci_probe().
base_dlyb = devm_of_iomap(mmc_dev(host->mmc), np, 1, NULL);
if (IS_ERR(base_dlyb))
--
2.17.1Well, I decided to help out a bit. I have amend the patch according to the above and extended the commit message with some valuable information, based upon our earlier discussions. Patch is applied at my fixes branch with a stable tag, please have a look, test and shout at me if there is something that looks wrong! Thanks and kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel