----- "Andy Fleming" <[email protected]> wrote:
> On Tue, Oct 11, 2011 at 4:51 AM, Ajay Bhargav
> <[email protected]> wrote:
> >
> > ----- "Ajay Bhargav" <[email protected]> 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 <[email protected]>
> >> ---
> >> 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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
