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