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

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

[Ajay Bhargav]

----- "Andy Fleming" <afleming@gmail.com> wrote:

> On Tue, Oct 11, 2011 at 4:51 AM, Ajay Bhargav
> <ajay.bhargav@einfochips.com> wrote:
> >
> > ----- "Ajay Bhargav" <ajay.bhargav@einfochips.com> 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 <ajay.bhargav@einfochips.com>
> >> ---
> >> ?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] [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.

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

[Ajay Bhargav]

----- "Andy Fleming" <afleming@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.
> 
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] [PATCH] mmc: CMD7:MMC_CMD_SELECT_CARD response fix

[Ajay Bhargav]

----- "Andy Fleming" <afleming@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

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

[Ajay Bhargav]

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 <ajay.bhargav@einfochips.com>
---
 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

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

[Ajay Bhargav]

----- "Ajay Bhargav" <ajay.bhargav@einfochips.com> 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 <ajay.bhargav@einfochips.com>
> ---
>  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 on this patch??

Regards,
Ajay Bhargav

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

[Ajay Bhargav]

----- "Ajay Bhargav" <ajay.bhargav@einfochips.com> 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 <ajay.bhargav@einfochips.com>
> ---
>  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?

Regards,
Ajay Bhargav

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

[Andy Fleming]

On Tue, Oct 11, 2011 at 4:51 AM, Ajay Bhargav
<ajay.bhargav@einfochips.com> wrote:
>
> ----- "Ajay Bhargav" <ajay.bhargav@einfochips.com> 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 <ajay.bhargav@einfochips.com>
>> ---
>> ?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?