>> 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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
