| Message ID | 20210225145454.12780-1-yann.gautier@foss.st.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] mmc: mmci: manage MMC_CAP_NEED_RSP_BUSY for stm32 variant | expand |
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
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
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) + 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; base_dlyb = devm_of_iomap(mmc_dev(host->mmc), np, 1, NULL); if (IS_ERR(base_dlyb))
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(-)