Re: [U-Boot] [PATCH] mmc: CMD7:MMC_CMD_SELECT_CARD response fix
----- "Andy Fleming" afleming@gmail.com wrote:
On Tue, Oct 11, 2011 at 4:51 AM, Ajay Bhargav ajay.bhargav@einfochips.com wrote:
----- "Ajay Bhargav" ajay.bhargav@einfochips.com wrote:
As per JEDEC document JESD84-A441 (page 105) response for CMD7 (MMC_CMD_SELECT_CARD) response should be R1 instead of R1b. In
uboot
we never take MMC to disconnected state and on powerup its always
ideal
state which later goes to stand-by state.
from document footnote: R1 while selecting from Stand-By State to Transfer State; R1b
while
selecting from Disconnected State to Programming State.
Signed-off-by: Ajay Bhargav ajay.bhargav@einfochips.com
drivers/mmc/mmc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index e384399..79d00f6 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -987,7 +987,7 @@ int mmc_startup(struct mmc *mmc) /* Select the card, and put it into Transfer Mode */ if (!mmc_host_is_spi(mmc)) { /* cmd not supported in spi */ cmd.cmdidx = MMC_CMD_SELECT_CARD;
- cmd.resp_type = MMC_RSP_R1b;
- cmd.resp_type = MMC_RSP_R1;
cmd.cmdarg = mmc->rca << 16; cmd.flags = 0; err = mmc_send_cmd(mmc, &cmd, NULL); -- 1.7.0.4
any comments?
I need to think about this. Was this causing you a problem? What were the symptoms?
yes... I am working on adding mmc support for Marvell GplugD board (Armada168 SoC). So during mmc startup, MMC_CMD_SELECT_CARD(CMD7) gets timed out. So digging more I found out that CMD7 in driver was expecting R1b instead of R1. I referred SD specs and JEDEC document for confirmation, and it clearly said in its footnote (which I added to patch description) that from stand-by to transfer mode response will be R1. I even crosschecked mmc driver in Kernel code, where in function mmc_select_card; CMD7 response is expected to be R1.
I also checked if the standard SDHCI driver I am using is at fault or what, But I did not find any problem with mmc driver (sdhci.c). I then referred to blackfin SDH driver to see how they are handing this... so they are kind of bypassing this. According to specs, for R1b one should wait for CMD_SENT and data end flag to get set as card may send busy response. whereas blackfin driver simply checks if any of the flag is set it comes out of loop see code below for reference.
ref bfin_sdh.c [..] /* wait for a while */ timeout = 0; do { if (++timeout > 1000000) { status = CMD_TIME_OUT; break; } udelay(1); status = bfin_read_SDH_STATUS(); } while (!(status & (CMD_SENT | CMD_RESP_END | CMD_TIME_OUT | CMD_CRC_FAIL)));
Incase of sdhci, driver waits for response endlessly. till both SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END flags are set.
I hope I am able to clear the issue?
Regards, Ajay Bhargav
I need to think about this. Was this causing you a problem? What were the symptoms?
yes... I am working on adding mmc support for Marvell GplugD board (Armada168 SoC). So during mmc startup, MMC_CMD_SELECT_CARD(CMD7) gets timed out. So digging more I found out that CMD7 in driver was expecting R1b instead of R1. I referred SD specs and JEDEC document for confirmation, and it clearly said in its footnote (which I added to patch description) that from stand-by to transfer mode response will be R1. I even crosschecked mmc driver in Kernel code, where in function mmc_select_card; CMD7 response is expected to be R1.
I also checked if the standard SDHCI driver I am using is at fault or what, But I did not find any problem with mmc driver (sdhci.c). I then referred to blackfin SDH driver to see how they are handing this... so they are kind of bypassing this. According to specs, for R1b one should wait for CMD_SENT and data end flag to get set as card may send busy response. whereas blackfin driver simply checks if any of the flag is set it comes out of loop see code below for reference.
ref bfin_sdh.c [..] /* wait for a while */ timeout = 0; do { if (++timeout > 1000000) { status = CMD_TIME_OUT; break; } udelay(1); status = bfin_read_SDH_STATUS(); } while (!(status & (CMD_SENT | CMD_RESP_END | CMD_TIME_OUT | CMD_CRC_FAIL)));
Incase of sdhci, driver waits for response endlessly. till both SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END flags are set.
I hope I am able to clear the issue?
Yes, that sounds fine, then. I'll apply it for this release.
----- "Andy Fleming" afleming@gmail.com wrote:
I need to think about this. Was this causing you a problem? What
were
the symptoms?
yes... I am working on adding mmc support for Marvell GplugD board
(Armada168 SoC). So during mmc startup, MMC_CMD_SELECT_CARD(CMD7) gets timed out. So digging more I found out that CMD7 in driver was expecting R1b instead of R1. I referred SD specs and JEDEC document for confirmation, and it clearly said in its footnote (which I added to patch description) that from stand-by to transfer mode response will be R1. I even crosschecked mmc driver in Kernel code, where in function mmc_select_card; CMD7 response is expected to be R1.
I also checked if the standard SDHCI driver I am using is at fault
or what, But I did not find any problem with mmc driver (sdhci.c). I then referred to blackfin SDH driver to see how they are handing this... so they are kind of bypassing this. According to specs, for R1b one should wait for CMD_SENT and data end flag to get set as card may send busy response. whereas blackfin driver simply checks if any of the flag is set it comes out of loop see code below for reference.
ref bfin_sdh.c [..] /* wait for a while */ timeout = 0; do { if (++timeout > 1000000) { status = CMD_TIME_OUT; break; } udelay(1); status = bfin_read_SDH_STATUS(); } while (!(status & (CMD_SENT | CMD_RESP_END | CMD_TIME_OUT
|
CMD_CRC_FAIL)));
Incase of sdhci, driver waits for response endlessly. till both
SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END flags are set.
I hope I am able to clear the issue?
Yes, that sounds fine, then. I'll apply it for this release.
Dear Andy,
Can you please send me an ack message :) just to have a confirmation? coz I have few patches for SDHCI driver, I will submit that too.
Regards, Ajay Bhargav
participants (2)
-
Ajay Bhargav -
Andy Fleming