Messages in this thread | | | Subject | Re: [PATCH v2] mmc: mmci: manage MMC_CAP_NEED_RSP_BUSY for stm32 variant | From | Yann Gautier <> | Date | Tue, 2 Mar 2021 15:06:50 +0100 |
| |
On 3/2/21 11:40 AM, Ulf Hansson wrote: > On Thu, 25 Feb 2021 at 15:55, Yann Gautier <yann.gautier@foss.st.com> wrote: >> >> 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 <yann.gautier@foss.st.com> >> --- >> 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) > >> + 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.1 >> > > Well, 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 >
Hi Ulf,
Thanks a lot for the updated patch. I've tested it on STM32MP157C-EV1. The MMC_TEST full campaigns for both SD-card and eMMC run OK.
Best regards, Yann
| |