[U-Boot] [PATCH] mmc: CMD7:MMC_CMD_SELECT_CARD response fix

[Ajay Bhargav]

----- "Andy Fleming" <afleming at gmail.com> wrote:

> On Tue, Oct 11, 2011 at 4:51 AM, Ajay Bhargav
> <ajay.bhargav at einfochips.com> wrote:
> >
> > ----- "Ajay Bhargav" <ajay.bhargav at 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 at 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