[U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Signed-off-by: Marek Vasut marek.vasut+renesas@gmail.com Cc: Jaehoon Chung jh80.chung@samsung.com --- NOTE: Linux does the same thing. --- drivers/mmc/mmc.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c7730c9233..ababacf65a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) return err; }
-int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value, + bool send_status) { struct mmc_cmd cmd; int timeout = 1000; @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) while (retries > 0) { ret = mmc_send_cmd(mmc, &cmd, NULL);
- /* Waiting for the ready status */ - if (!ret) { - ret = mmc_send_status(mmc, timeout); - return ret; + if (ret) { + retries--; + continue; + } + + if (!send_status) { + mdelay(50); + return 0; }
- retries--; + /* Waiting for the ready status */ + return mmc_send_status(mmc, timeout); }
return ret;
}
+int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +{ + return __mmc_switch(mmc, set, index, value, true); +} + #if !CONFIG_IS_ENABLED(MMC_TINY) static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, bool hsdowngrade) @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, default: return -EINVAL; } - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, - speed_bits); + + err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, + speed_bits, !hsdowngrade); if (err) return err;
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Signed-off-by: Marek Vasut marek.vasut+renesas@gmail.com Cc: Jaehoon Chung jh80.chung@samsung.com
NOTE: Linux does the same thing.
drivers/mmc/mmc.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c7730c9233..ababacf65a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) return err; }
-int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
bool send_status)@@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) while (retries > 0) { ret = mmc_send_cmd(mmc, &cmd, NULL);
/* Waiting for the ready status */if (!ret) {ret = mmc_send_status(mmc, timeout);return ret;
if (ret) {retries--;continue;}if (!send_status) {mdelay(50);return 0;
retries--;
/* Waiting for the ready status */return mmc_send_status(mmc, timeout);}
return ret;
}
+int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +{
- return __mmc_switch(mmc, set, index, value, true);
+}
- #if !CONFIG_IS_ENABLED(MMC_TINY) static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, bool hsdowngrade)
@@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, default: return -EINVAL; }
- err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
speed_bits);
- err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
speed_bits, !hsdowngrade);
Reviewed-by: Jean-Jacques Hiblot jjhiblot@ti.com
Hi Marek,
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Nit: mS -> ms
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Just out of curiosity - is this 50ms time written in some spec? Or is it only specific to Renesas HS200/HS400 ?
Signed-off-by: Marek Vasut marek.vasut+renesas@gmail.com Cc: Jaehoon Chung jh80.chung@samsung.com
NOTE: Linux does the same thing.
drivers/mmc/mmc.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c7730c9233..ababacf65a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) return err; }
-int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
bool send_status){ struct mmc_cmd cmd; int timeout = 1000; @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) while (retries > 0) { ret = mmc_send_cmd(mmc, &cmd, NULL);
/* Waiting for the ready status */if (!ret) {ret = mmc_send_status(mmc, timeout);return ret;
if (ret) {retries--;continue;}if (!send_status) {mdelay(50);return 0;
retries--;
/* Waiting for the ready status */return mmc_send_status(mmc, timeout);}
return ret;
}
+int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +{
- return __mmc_switch(mmc, set, index, value, true);
+}
#if !CONFIG_IS_ENABLED(MMC_TINY) static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, bool hsdowngrade) @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, default: return -EINVAL; }
- err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_HS_TIMING,
speed_bits);
- err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_HS_TIMING,
speed_bits, !hsdowngrade);
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
JJ
Signed-off-by: Marek Vasut marek.vasut+renesas@gmail.com Cc: Jaehoon Chung jh80.chung@samsung.com
NOTE: Linux does the same thing.
drivers/mmc/mmc.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c7730c9233..ababacf65a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) return err; }
-int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
bool send_status)@@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) while (retries > 0) { ret = mmc_send_cmd(mmc, &cmd, NULL);
/* Waiting for the ready status */if (!ret) {ret = mmc_send_status(mmc, timeout);return ret;
if (ret) {retries--;continue;}if (!send_status) {mdelay(50);return 0;
retries--;
/* Waiting for the ready status */return mmc_send_status(mmc, timeout);}
return ret;
}
+int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +{
- return __mmc_switch(mmc, set, index, value, true);
+}
- #if !CONFIG_IS_ENABLED(MMC_TINY) static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, bool hsdowngrade)
@@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, default: return -EINVAL; }
- err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
speed_bits);
- err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
speed_bits, !hsdowngrade);
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
[...]
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
I'm asking because this is a 50ms delay in the hot path of the boot process.
JJ
[...]
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the new state and is reliably ready ? You can't, because you cannot communicate with the card -- which is the entire problem here, you have no way to communicate with the card while the bus is switching. However, you can wait the maximum allowed time according to the spec, and then the bus/card must be ready. If not, all bets are off.
I'm asking because this is a 50ms delay in the hot path of the boot process.
I totally understand that, I have the same issue with HS200/HS400 on R-Car Gen3, all the calibration shenanigans and this indeed add quite a bit to the boot time. But I don't have a good answer here.
On 25/06/2019 21:47, Marek Vasut wrote:
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the new state and is reliably ready ? You can't, because you cannot communicate with the card -- which is the entire problem here, you have no way to communicate with the card while the bus is switching. However, you can wait the maximum allowed time according to the spec, and then the bus/card must be ready. If not, all bets are off.
I'm asking because this is a 50ms delay in the hot path of the boot process.
I totally understand that, I have the same issue with HS200/HS400 on R-Car Gen3, all the calibration shenanigans and this indeed add quite a* bit to the boot time. But I don't have a good answer here.
I'll post something using the existing wait_dat0() callback. If the callback is implemented, we can forgo the 50ms delay and poll the dat0 line.
On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
On 25/06/2019 21:47, Marek Vasut wrote:
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the new state and is reliably ready ? You can't, because you cannot communicate with the card -- which is the entire problem here, you have no way to communicate with the card while the bus is switching. However, you can wait the maximum allowed time according to the spec, and then the bus/card must be ready. If not, all bets are off.
I'm asking because this is a 50ms delay in the hot path of the boot process.
I totally understand that, I have the same issue with HS200/HS400 on R-Car Gen3, all the calibration shenanigans and this indeed add quite a* bit to the boot time. But I don't have a good answer here.
I'll post something using the existing wait_dat0() callback. If the callback is implemented, we can forgo the 50ms delay and poll the dat0 line.
We can ? Do you have some more details ?
On 26/06/2019 11:50, Marek Vasut wrote:
On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
On 25/06/2019 21:47, Marek Vasut wrote:
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote: > When using CMD6 to switch eMMC card timing from HS200/HS400 to > HS/legacy, > do not poll for the completion status using CMD13, but rather wait > 50mS. > > Once the card receives the CMD6 and starts executing it, the bus > is in > undefined state until both the card finishes executing the command > and > until the controller switches the bus to matching timing > configuration. > During this time, it is not possible to transport any commands or > data > across the bus, which includes the CMD13. Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen the same kind of problems. But they mostly go away If the code handling the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the new state and is reliably ready ? You can't, because you cannot communicate with the card -- which is the entire problem here, you have no way to communicate with the card while the bus is switching. However, you can wait the maximum allowed time according to the spec, and then the bus/card must be ready. If not, all bets are off.
I'm asking because this is a 50ms delay in the hot path of the boot process.
I totally understand that, I have the same issue with HS200/HS400 on R-Car Gen3, all the calibration shenanigans and this indeed add quite a* bit to the boot time. But I don't have a good answer here.
I'll post something using the existing wait_dat0() callback. If the callback is implemented, we can forgo the 50ms delay and poll the dat0 line.
We can ? Do you have some more details ?
dat0 is a rdy/busy indicator. In the linux driver it is used in the card_busy() callback (look at sdhci_card_busy() for an example).
In u-boot we have a wait_dat0() that polls on dat0. It is used during the UHS initialization.
On 6/26/19 2:21 PM, Jean-Jacques Hiblot wrote:
On 26/06/2019 11:50, Marek Vasut wrote:
On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
On 25/06/2019 21:47, Marek Vasut wrote:
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
On 25/06/2019 17:53, Marek Vasut wrote:
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote: > Hi Marek, > > On 06/02/2019 14:11, Marek Vasut wrote: >> When using CMD6 to switch eMMC card timing from HS200/HS400 to >> HS/legacy, >> do not poll for the completion status using CMD13, but rather wait >> 50mS. >> >> Once the card receives the CMD6 and starts executing it, the bus >> is in >> undefined state until both the card finishes executing the command >> and >> until the controller switches the bus to matching timing >> configuration. >> During this time, it is not possible to transport any commands or >> data >> across the bus, which includes the CMD13. > Is it something that affects all platforms ? > > I've been working on this on TI platforms lately and although I've > seen > the same kind of problems. But they mostly go away If the code > handling > the switch handles the SWITCH_ERROR bit. The error probably happens because you send the card a command, but the command hits the bus that's in some weird intermediate state. Either the card didn't finish switching the bus properties yet, or it did, or it's in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state, shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the new state and is reliably ready ? You can't, because you cannot communicate with the card -- which is the entire problem here, you have no way to communicate with the card while the bus is switching. However, you can wait the maximum allowed time according to the spec, and then the bus/card must be ready. If not, all bets are off.
I'm asking because this is a 50ms delay in the hot path of the boot process.
I totally understand that, I have the same issue with HS200/HS400 on R-Car Gen3, all the calibration shenanigans and this indeed add quite a* bit to the boot time. But I don't have a good answer here.
I'll post something using the existing wait_dat0() callback. If the callback is implemented, we can forgo the 50ms delay and poll the dat0 line.
We can ? Do you have some more details ?
dat0 is a rdy/busy indicator. In the linux driver it is used in the card_busy() callback (look at sdhci_card_busy() for an example).
In u-boot we have a wait_dat0() that polls on dat0. It is used during the UHS initialization.
All right, let's try this.
participants (3)
-
Jean-Jacques Hiblot -
Lukasz Majewski -
Marek Vasut