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

[Andy Fleming]

>> 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.