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

[Ajay Bhargav]

----- "Andy Fleming" <afleming at 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.
> 
waited long for this reply :D thanks... 

Cheers!
Ajay Bhargav