linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0
@ 2019-04-09 11:05 Yoshihiro Shimoda
  2019-04-18  6:45 ` Wolfram Sang
  2019-04-29 10:44 ` Ulf Hansson
  0 siblings, 2 replies; 3+ messages in thread
From: Yoshihiro Shimoda @ 2019-04-09 11:05 UTC (permalink / raw)
  To: ulf.hansson; +Cc: linux-mmc, linux-renesas-soc, Yoshihiro Shimoda

According to eMMC specification v5.1 section 6.4.3, we should issue
CMD1 repeatedly in the idle state until the eMMC is ready even if
the mmc_attach_mmc() calls this function with ocr = 0. Otherwise
some eMMC devices seems to enter the inactive mode after
mmc_init_card() issued CMD0 when the eMMC device is busy.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
 Changes from v1 (https://patchwork.kernel.org/patch/10874619/):
 - Revise the comment on the source code.

 We can reproduce this issue if:
  - we add no-sd and no-sdio property into sdhi2 node of salvator-common.dtsi,
  - the renesas_sdhi driver is kernel module,
  - Using a Salvator-XS board that has Samsung eMMC device,
  - enter suspend and exit it,
  - and then insmod renesas_sdhi_{core,internal_dmac}.ko.

 After that, the following error happened and any partitions are not detected.
  mmc1: error -110 whilst initialising MMC card

 I tested this patch on:
  - M3-N Salvator-XS with a Samsung eMMC device,
  - M3-W Salvator-X with SiliconMotion eMMC device,
  - and M3-W Starter Kit with Micron eMMC device.

 drivers/mmc/core/mmc_ops.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index c5208fb..a533cab 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -184,11 +184,7 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
 		if (err)
 			break;
 
-		/* if we're just probing, do a single pass */
-		if (ocr == 0)
-			break;
-
-		/* otherwise wait until reset completes */
+		/* wait until reset completes */
 		if (mmc_host_is_spi(host)) {
 			if (!(cmd.resp[0] & R1_SPI_IDLE))
 				break;
@@ -200,6 +196,16 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
 		err = -ETIMEDOUT;
 
 		mmc_delay(10);
+
+		/*
+		 * According to eMMC specification v5.1 section 6.4.3, we
+		 * should issue CMD1 repeatedly in the idle state until
+		 * the eMMC is ready. Otherwise some eMMC devices seem to enter
+		 * the inactive mode after mmc_init_card() issued CMD0 when
+		 * the eMMC device is busy.
+		 */
+		if (!ocr && !mmc_host_is_spi(host))
+			cmd.arg = cmd.resp[0] | BIT(30);
 	}
 
 	if (rocr && !mmc_host_is_spi(host))
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0
  2019-04-09 11:05 [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0 Yoshihiro Shimoda
@ 2019-04-18  6:45 ` Wolfram Sang
  2019-04-29 10:44 ` Ulf Hansson
  1 sibling, 0 replies; 3+ messages in thread
From: Wolfram Sang @ 2019-04-18  6:45 UTC (permalink / raw)
  To: Yoshihiro Shimoda; +Cc: ulf.hansson, linux-mmc, linux-renesas-soc

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Tue, Apr 09, 2019 at 08:05:06PM +0900, Yoshihiro Shimoda wrote:
> According to eMMC specification v5.1 section 6.4.3, we should issue
> CMD1 repeatedly in the idle state until the eMMC is ready even if
> the mmc_attach_mmc() calls this function with ocr = 0. Otherwise
> some eMMC devices seems to enter the inactive mode after
> mmc_init_card() issued CMD0 when the eMMC device is busy.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
>  Changes from v1 (https://patchwork.kernel.org/patch/10874619/):
>  - Revise the comment on the source code.

I like the new comment, very clear, thank you!

I didn't test this change but I double checked the specs and the code
matches them to the best of my understanding:

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0
  2019-04-09 11:05 [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0 Yoshihiro Shimoda
  2019-04-18  6:45 ` Wolfram Sang
@ 2019-04-29 10:44 ` Ulf Hansson
  1 sibling, 0 replies; 3+ messages in thread
From: Ulf Hansson @ 2019-04-29 10:44 UTC (permalink / raw)
  To: Yoshihiro Shimoda; +Cc: linux-mmc, Linux-Renesas

On Tue, 9 Apr 2019 at 13:09, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
>
> According to eMMC specification v5.1 section 6.4.3, we should issue
> CMD1 repeatedly in the idle state until the eMMC is ready even if
> the mmc_attach_mmc() calls this function with ocr = 0. Otherwise
> some eMMC devices seems to enter the inactive mode after
> mmc_init_card() issued CMD0 when the eMMC device is busy.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

Applied for next, thanks!

Let's get some test coverage of this before we decide if this a
material for stable.

Kind regards
Uffe


> ---
>  Changes from v1 (https://patchwork.kernel.org/patch/10874619/):
>  - Revise the comment on the source code.
>
>  We can reproduce this issue if:
>   - we add no-sd and no-sdio property into sdhi2 node of salvator-common.dtsi,
>   - the renesas_sdhi driver is kernel module,
>   - Using a Salvator-XS board that has Samsung eMMC device,
>   - enter suspend and exit it,
>   - and then insmod renesas_sdhi_{core,internal_dmac}.ko.
>
>  After that, the following error happened and any partitions are not detected.
>   mmc1: error -110 whilst initialising MMC card
>
>  I tested this patch on:
>   - M3-N Salvator-XS with a Samsung eMMC device,
>   - M3-W Salvator-X with SiliconMotion eMMC device,
>   - and M3-W Starter Kit with Micron eMMC device.
>
>  drivers/mmc/core/mmc_ops.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index c5208fb..a533cab 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -184,11 +184,7 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
>                 if (err)
>                         break;
>
> -               /* if we're just probing, do a single pass */
> -               if (ocr == 0)
> -                       break;
> -
> -               /* otherwise wait until reset completes */
> +               /* wait until reset completes */
>                 if (mmc_host_is_spi(host)) {
>                         if (!(cmd.resp[0] & R1_SPI_IDLE))
>                                 break;
> @@ -200,6 +196,16 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
>                 err = -ETIMEDOUT;
>
>                 mmc_delay(10);
> +
> +               /*
> +                * According to eMMC specification v5.1 section 6.4.3, we
> +                * should issue CMD1 repeatedly in the idle state until
> +                * the eMMC is ready. Otherwise some eMMC devices seem to enter
> +                * the inactive mode after mmc_init_card() issued CMD0 when
> +                * the eMMC device is busy.
> +                */
> +               if (!ocr && !mmc_host_is_spi(host))
> +                       cmd.arg = cmd.resp[0] | BIT(30);
>         }
>
>         if (rocr && !mmc_host_is_spi(host))
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-04-29 10:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-09 11:05 [PATCH v2] mmc: core: retry CMD1 in mmc_send_op_cond() even if the ocr = 0 Yoshihiro Shimoda
2019-04-18  6:45 ` Wolfram Sang
2019-04-29 10:44 ` Ulf Hansson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).