[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Pali Rohár]

Hello,

after commit 02f3029f1810b99869254d0cf0a71946a008a728 mmc: retry the cmd8 to 
meet 74 clocks requirement in the spec

internal eMMC memory on Nokia N900 in u-boot not working. If I comment code 
"if (err) return err;" added by this commit, eMMC working fine.

More info: mmc_send_if_cond from drivers/mmc/mmc.c is calling function 
mmc_send_cmd in drivers/mmc/omap_hsmmc.c which returning TIMEOUT from line 
278:
	if ((mmc_stat & IE_CTO) != 0)
		return TIMEOUT;

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111112/dc27eddb/attachment.pgp 

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Lei Wen]

Hi Pali,

On Sat, Nov 12, 2011 at 7:17 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> Hello,
>
> after commit 02f3029f1810b99869254d0cf0a71946a008a728 mmc: retry the cmd8 to
> meet 74 clocks requirement in the spec
>
> internal eMMC memory on Nokia N900 in u-boot not working. If I comment code
> "if (err) return err;" added by this commit, eMMC working fine.
>
> More info: mmc_send_if_cond from drivers/mmc/mmc.c is calling function
> mmc_send_cmd in drivers/mmc/omap_hsmmc.c which returning TIMEOUT from line
> 278:
> ? ? ? ?if ((mmc_stat & IE_CTO) != 0)
> ? ? ? ? ? ? ? ?return TIMEOUT;
>
> --
> Pali Roh?r
> pali.rohar at gmail.com
>

It is strange that your card would still get failed to send CMD8 after
3 times retry.
Does omap mmc controller has some mechanism of mmc dynamic clock gating?
I would suggest you to investigate why the emmc cannot response to CMD8 first.
If not, I think we could make this err return code included in a ifdef
to workaround
your issue.


Thanks,
Lei

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

Hi Lei Wen,

2011/11/12 Lei Wen <adrian.wenl@gmail.com>:
> Hi Pali,
>
> It is strange that your card would still get failed to send CMD8 after
> 3 times retry.
> Does omap mmc controller has some mechanism of mmc dynamic clock gating?
> I would suggest you to investigate why the emmc cannot response to CMD8 first.
> If not, I think we could make this err return code included in a ifdef
> to workaround
> your issue.
>

I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too.
But I'm not sure where the problem is and hasn't start to check bisect
with the commits.
It works really fine before.
That's why I asked Andy to stop review the performance improvement of FTSDC010.
Maybe we'll need to check it again where the affect is started.--
Best regards,
Macpaul Lin

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

HI Lei Wen,

2011/11/12 Macpaul Lin <macpaul@gmail.com>:
> Hi Lei Wen,
>
> 2011/11/12 Lei Wen <adrian.wenl@gmail.com>:
>> Hi Pali,
>>
> I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too.
> But I'm not sure where the problem is and hasn't start to check bisect
> with the commits.
> It works really fine before.
> That's why I asked Andy to stop review the performance improvement of FTSDC010.
> Maybe we'll need to check it again where the affect is started.--
> Best regards,
> Macpaul Lin
>

I have done the testing of the commit related to mmc generic stack of
Lei Wen's commit.
The problem indeed occur when we add 3 retry to CMD8.
After reverting this patch with the origin ftsdc010 driver (which is
in master branch alredy),
all works fine again.

The following is the command flow with origin mmc stack.
When I'm using card which version is SD 1.10, the CMD8 will timeout
directly then card identification will continue.

cmd 0
cmd: 8
ftsdc010_pio_check_status: RSP timeout: sta: 00000004 cmd 8
cmd: 55
cmd: 41
cmd: 55...

If we add 3 retry to CMD8, the card will reply timeout 3 times than stop.
It won't go to CMD55.
cmd: 0
cmd: 8
ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8
cmd: 8
ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8
cmd: 8
ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8



-- 
Best regards,
Macpaul Lin

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Lei Wen]

Hi Macpaul,

On Mon, Nov 14, 2011 at 2:14 PM, Macpaul Lin <macpaul@gmail.com> wrote:
> HI Lei Wen,
>
> 2011/11/12 Macpaul Lin <macpaul@gmail.com>:
>> Hi Lei Wen,
>>
>> 2011/11/12 Lei Wen <adrian.wenl@gmail.com>:
>>> Hi Pali,
>>>
>> I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too.
>> But I'm not sure where the problem is and hasn't start to check bisect
>> with the commits.
>> It works really fine before.
>> That's why I asked Andy to stop review the performance improvement of FTSDC010.
>> Maybe we'll need to check it again where the affect is started.--
>> Best regards,
>> Macpaul Lin
>>
>
> I have done the testing of the commit related to mmc generic stack of
> Lei Wen's commit.
> The problem indeed occur when we add 3 retry to CMD8.
> After reverting this patch with the origin ftsdc010 driver (which is
> in master branch alredy),
> all works fine again.
>
> The following is the command flow with origin mmc stack.
> When I'm using card which version is SD 1.10, the CMD8 will timeout
> directly then card identification will continue.
>
> cmd 0
> cmd: 8
> ftsdc010_pio_check_status: RSP timeout: sta: 00000004 cmd 8
> cmd: 55
> cmd: 41
> cmd: 55...
>
> If we add 3 retry to CMD8, the card will reply timeout 3 times than stop.
> It won't go to CMD55.
> cmd: 0
> cmd: 8
> ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8
> cmd: 8
> ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8
> cmd: 8
> ftsdc010_pio_check_status: RSP timeout: sta: 00000404 cmd 8
>
>
I see...
It seems some socs always treat cmd8 as failed...?
I think it is reasonable to add a quirk configuration surround the judgement
of cmd8 execution, so that even it is failed anyway, it could still go on with
the following cmd sequence. If this quirk is not defined, and return behavior
is still kept.

What do you think for this?

Thanks,
Lei

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

Hi Lei Wen,

2011/11/14 Lei Wen <adrian.wenl@gmail.com>:
> Hi Macpaul,
>
> I see...
> It seems some socs always treat cmd8 as failed...?
> I think it is reasonable to add a quirk configuration surround the judgement
> of cmd8 execution, so that even it is failed anyway, it could still go on with
> the following cmd sequence. If this quirk is not defined, and return behavior
> is still kept.
>
> What do you think for this?
>
> Thanks,
> Lei
>

I've not check this with the SD phy specification.
The command process should be backward compatible between 3.0 and 1.0.

Could you please provide this more detail with the specification?
For example, could you please provide what section in the specification
and how the state machine in MMC card should be operated.
Then we can check it more detail and see if the solution is reasonable.

Moreover, if you could provide where the Linux code is related to the problem
and how dose Linux deal with this problem will be good, also.

As you said in patch, "some card strictly obey the 74 clocks rule",
could you provide the information of the card that you're using?

Add #ifdef to the code is a quick solution, but I think the we need to
figure out if there is other method
to help on 74 clock adoptable on more general case.

-- 
Best regards,
Macpaul Lin

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Lei Wen]

Hi Macpaul,

On Mon, Nov 14, 2011 at 2:36 PM, Macpaul Lin <macpaul@gmail.com> wrote:
> Hi Lei Wen,
>
> 2011/11/14 Lei Wen <adrian.wenl@gmail.com>:
>> Hi Macpaul,
>>
>> I see...
>> It seems some socs always treat cmd8 as failed...?
>> I think it is reasonable to add a quirk configuration surround the judgement
>> of cmd8 execution, so that even it is failed anyway, it could still go on with
>> the following cmd sequence. If this quirk is not defined, and return behavior
>> is still kept.
>>
>> What do you think for this?
>>
>> Thanks,
>> Lei
>>
>
> I've not check this with the SD phy specification.
> The command process should be backward compatible between 3.0 and 1.0.
>
> Could you please provide this more detail with the specification?
> For example, could you please provide what section in the specification
> and how the state machine in MMC card should be operated.
> Then we can check it more detail and see if the solution is reasonable.

The 74 clock requirement is mentioned in both sd[1] and mmc spec[2].
[1] page 91, section 6.4.1 power up, SD specification, part 1,
Physical layer Simplificated Specification, version 2.0
[2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44

>
> Moreover, if you could provide where the Linux code is related to the problem
> and how dose Linux deal with this problem will be good, also.

For linux, it would direcly clear the HIGH SPEED flag for following
mmc_send_app_op_cond().
Linux v3.2-rc1: drivers/mmc/core/sd.c: line 712

>
> As you said in patch, "some card strictly obey the 74 clocks rule",
> could you provide the information of the card that you're using?

The card we met trouble on is SanDisk 8GB class4 sd card.

>
> Add #ifdef to the code is a quick solution, but I think the we need to
> figure out if there is other method
> to help on 74 clock adoptable on more general case.
>
> --
> Best regards,
> Macpaul Lin
>

Best regards,
Lei

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

HI Lei Wen,

2011/11/14 Lei Wen <adrian.wenl@gmail.com>:
> Hi Macpaul,
>
>>> It seems some socs always treat cmd8 as failed...?
>>> I think it is reasonable to add a quirk configuration surround the judgement
>>> of cmd8 execution, so that even it is failed anyway, it could still go on with
>>> the following cmd sequence. If this quirk is not defined, and return behavior
>>> is still kept.
>>>
>>> What do you think for this?
>>>
>>> Thanks,
>>> Lei
>>>

For easily to discuss about this problem, I've stripped the part from
SD specification 3.0 as you mentioned.

Figure 6.1
http://i.imgur.com/bmoAX.jpg
Figure 6.2
http://i.imgur.com/7fxdx.jpg

As you can see, after the power ramp up to 74 clocks (1msec), the CMD0
can be send to the card.

So it seems your controller will do power ramp up (dynamic clock
gating?) "only after" the CMD0 has been send?
Is this correct? However, it is weird and seem not followed the specification.

Since only SD 2.0 cards can adopted with CMD8, other cards older than
SD 2.0 should treat CMD8 as timeout (I guess).
So CMD8 might be important for us to distinguish  the command sequence.
Sending CMD8 many times might really introduce problem for other cards.

> The 74 clock requirement is mentioned in both sd[1] and mmc spec[2].
> [1] page 91, section 6.4.1 power up, SD specification, part 1,
> Physical layer Simplificated Specification, version 2.0
> [2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44
>

> The card we met trouble on is SanDisk 8GB class4 sd card.

I don't have this card on hand. I only have Samsung and Trenscend
cards (SD2.0, SD1.10 / class4 or class10).
Is this SanDisk card also a SD 1.10 cards?

>> Add #ifdef to the code is a quick solution, but I think the we need to
>> figure out if there is other method
>> to help on 74 clock adoptable on more general case.
>>

It seems you can only add #ifdef related to your controller
(which means, do not add #ifdef as default to all other controllers.)

Have you tried to fix it with more delay after sending CMD0?
While mmc_go_idle have udelay(2000), which is 2ms, maybe writing a
wrapper (command filter) function in your driver to force it wait longer after
CMD0 has been send will be better.

However it might lead a little bit drawback for the driver performance.
But I think it won't be too much, only an "if" statement is enough.
Thus you won't affect the behavior of the mmc software stack, and also will be
more trivial to avoid adding #ifdef for special controller.

Just a suggestion, hope other people could give comments. :-)


-- 
Best regards,
Macpaul Lin

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Lei Wen]

Hi Macpaul,

On Tue, Nov 15, 2011 at 11:34 AM, Macpaul Lin <macpaul@gmail.com> wrote:
> HI Lei Wen,
>
> 2011/11/14 Lei Wen <adrian.wenl@gmail.com>:
>> Hi Macpaul,
>>
>>>> It seems some socs always treat cmd8 as failed...?
>>>> I think it is reasonable to add a quirk configuration surround the judgement
>>>> of cmd8 execution, so that even it is failed anyway, it could still go on with
>>>> the following cmd sequence. If this quirk is not defined, and return behavior
>>>> is still kept.
>>>>
>>>> What do you think for this?
>>>>
>>>> Thanks,
>>>> Lei
>>>>
>
> For easily to discuss about this problem, I've stripped the part from
> SD specification 3.0 as you mentioned.
>
> Figure 6.1
> http://i.imgur.com/bmoAX.jpg
> Figure 6.2
> http://i.imgur.com/7fxdx.jpg
>
> As you can see, after the power ramp up to 74 clocks (1msec), the CMD0
> can be send to the card.
>
> So it seems your controller will do power ramp up (dynamic clock
> gating?) "only after" the CMD0 has been send?
> Is this correct? However, it is weird and seem not followed the specification.

Yes, our controller use dynamic control gating for clock. The clock is
not sample out
while no command send out.

>
> Since only SD 2.0 cards can adopted with CMD8, other cards older than
> SD 2.0 should treat CMD8 as timeout (I guess).
> So CMD8 might be important for us to distinguish ?the command sequence.
> Sending CMD8 many times might really introduce problem for other cards.

I realize now we at least cannot directly return err if the cmd8 is not succeed.
Please submit a patch to fix it.

Thanks,
Lei

[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

Hi Lei Wen,

2011/11/15 Lei Wen <adrian.wenl@gmail.com>:
> Hi Macpaul,
>
>> Figure 6.1
>> http://i.imgur.com/bmoAX.jpg
>> Figure 6.2
>> http://i.imgur.com/7fxdx.jpg
>>
>> As you can see, after the power ramp up to 74 clocks (1msec), the CMD0
>> can be send to the card.
>>
>> So it seems your controller will do power ramp up (dynamic clock
>> gating?) "only after" the CMD0 has been send?
>> Is this correct? However, it is weird and seem not followed the specification.
>
> Yes, our controller use dynamic control gating for clock. The clock is
> not sample out
> while no command send out.
>
> I realize now we at least cannot directly return err if the cmd8 is not succeed.
> Please submit a patch to fix it.
>
> Thanks,
> Lei
>

It seems your hardware doesn't follow the rule that specification
described and made
compatibility problem to other platform, includes the existing platforms.
I think you'd better report it to your hardware designer which is a
hardware bug need to be fixed.
And, I think you can send a quick fix patch like the #ifdef
as you've mention to workaround for your hardware "only" if you cannot
find a common solution right now.

-- 
Best regards,
Macpaul Lin

[U-Boot] [PATCH] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"

[Macpaul Lin]

This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.

This patch add 3 times retry to CMD8 because the Marvell mmc controller
doesn't obey the power ramp up process in the SD specification 6.4.1.
(Please refer to figure 6.1 and 6.2 in the specification.)

The CMD0 should be send after power ramp up has been finished.
However, the Marvell mmc contorller must do power ramp up after the
first CMD0 command has been send.

This patch also affect existing platforms like Nokia N900 and other
platforms.

Signed-off-by: Macpaul Lin <macpaul@andestech.com>
---
 drivers/mmc/mmc.c |   16 ++--------------
 1 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 37ce6e8..21665ec 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1190,7 +1190,7 @@ block_dev_desc_t *mmc_get_dev(int dev)
 
 int mmc_init(struct mmc *mmc)
 {
-	int err, retry = 3;
+	int err;
 
 	if (mmc->has_init)
 		return 0;
@@ -1213,19 +1213,7 @@ int mmc_init(struct mmc *mmc)
 	mmc->part_num = 0;
 
 	/* Test for SD version 2 */
-	/*
-	 * retry here for 3 times, as for some controller it has dynamic
-	 * clock gating, and only toggle out clk when the first cmd0 send
-	 * out, while some card strictly obey the 74 clocks rule, the interval
-	 * may not be sufficient between the cmd0 and this cmd8, retry to
-	 * fulfil the clock requirement
-	 */
-	do {
-		err = mmc_send_if_cond(mmc);
-	} while (--retry > 0 && err);
-
-	if (err)
-		return err;
+	err = mmc_send_if_cond(mmc);
 
 	/* Now try to get the SD card's operating condition */
 	err = sd_send_op_cond(mmc);
-- 
1.7.3.5

[U-Boot] [PATCH] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"

[Lei Wen]

On Tue, Nov 15, 2011 at 5:35 PM, Macpaul Lin <macpaul@andestech.com> wrote:
> This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.
>
> This patch add 3 times retry to CMD8 because the Marvell mmc controller
> doesn't obey the power ramp up process in the SD specification 6.4.1.
> (Please refer to figure 6.1 and 6.2 in the specification.)
>
> The CMD0 should be send after power ramp up has been finished.
> However, the Marvell mmc contorller must do power ramp up after the
> first CMD0 command has been send.
>
> This patch also affect existing platforms like Nokia N900 and other
> platforms.
>
> Signed-off-by: Macpaul Lin <macpaul@andestech.com>
> ---
> ?drivers/mmc/mmc.c | ? 16 ++--------------
> ?1 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 37ce6e8..21665ec 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1190,7 +1190,7 @@ block_dev_desc_t *mmc_get_dev(int dev)
>
> ?int mmc_init(struct mmc *mmc)
> ?{
> - ? ? ? int err, retry = 3;
> + ? ? ? int err;
>
> ? ? ? ?if (mmc->has_init)
> ? ? ? ? ? ? ? ?return 0;
> @@ -1213,19 +1213,7 @@ int mmc_init(struct mmc *mmc)
> ? ? ? ?mmc->part_num = 0;
>
> ? ? ? ?/* Test for SD version 2 */
> - ? ? ? /*
> - ? ? ? ?* retry here for 3 times, as for some controller it has dynamic
> - ? ? ? ?* clock gating, and only toggle out clk when the first cmd0 send
> - ? ? ? ?* out, while some card strictly obey the 74 clocks rule, the interval
> - ? ? ? ?* may not be sufficient between the cmd0 and this cmd8, retry to
> - ? ? ? ?* fulfil the clock requirement
> - ? ? ? ?*/
> - ? ? ? do {
> - ? ? ? ? ? ? ? err = mmc_send_if_cond(mmc);
> - ? ? ? } while (--retry > 0 && err);
> -
> - ? ? ? if (err)
> - ? ? ? ? ? ? ? return err;
> + ? ? ? err = mmc_send_if_cond(mmc);
>
> ? ? ? ?/* Now try to get the SD card's operating condition */
> ? ? ? ?err = sd_send_op_cond(mmc);
> --
> 1.7.3.5
>
>

Acked-by: Lei Wen <leiwen@marvell.com>

[U-Boot] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"

[Stephen Warren]

On 01/-10/-28163 12:59 PM, Macpaul Lin wrote:
> This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.
> 
> This patch add 3 times retry to CMD8 because the Marvell mmc controller
> doesn't obey the power ramp up process in the SD specification 6.4.1.
> (Please refer to figure 6.1 and 6.2 in the specification.)
> 
> The CMD0 should be send after power ramp up has been finished.
> However, the Marvell mmc contorller must do power ramp up after the
> first CMD0 command has been send.
> 
> This patch also affect existing platforms like Nokia N900 and other
> platforms.
> 
> Signed-off-by: Macpaul Lin <macpaul@andestech.com>
> Acked-by: Lei Wen <leiwen@marvell.com>

Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>

As background, I'm working on patches to support the Toshiba AC100 /
Dynabook AZ in mainline U-Boot. The internal MMC didn't work at all
until this revert was applied. The SD slot worked perfectly though. I
guess this is related to the MMC itself not supporting this
(SD-specific?) command, and the patch caused MMC mode never to be attempted.

[U-Boot] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"

[Pali Rohár]

On Saturday 19 November 2011 12:36:00 Stephen Warren wrote:
> On 01/-10/-28163 12:59 PM, Macpaul Lin wrote:
> > This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.
> > 
> > This patch add 3 times retry to CMD8 because the Marvell mmc controller
> > doesn't obey the power ramp up process in the SD specification 6.4.1.
> > (Please refer to figure 6.1 and 6.2 in the specification.)
> > 
> > The CMD0 should be send after power ramp up has been finished.
> > However, the Marvell mmc contorller must do power ramp up after the
> > first CMD0 command has been send.
> > 
> > This patch also affect existing platforms like Nokia N900 and other
> > platforms.
> > 
> > Signed-off-by: Macpaul Lin <macpaul@andestech.com>
> > Acked-by: Lei Wen <leiwen@marvell.com>
> 
> Acked-by: Stephen Warren <swarren@nvidia.com>
> Tested-by: Stephen Warren <swarren@nvidia.com>
> 
> As background, I'm working on patches to support the Toshiba AC100 /
> Dynabook AZ in mainline U-Boot. The internal MMC didn't work at all
> until this revert was applied. The SD slot worked perfectly though. I
> guess this is related to the MMC itself not supporting this
> (SD-specific?) command, and the patch caused MMC mode never to be attempted.

Same for Nokia N900 (SD slot working fine). After reverting commit 
02f3029f1810b99869254d0cf0a71946a008a728 internal eMMC working too.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111119/bbe37370/attachment.pgp>

[U-Boot] [PATCH] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"

[Andy Fleming]

On Tue, Nov 15, 2011 at 3:35 AM, Macpaul Lin <macpaul@andestech.com> wrote:
> This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.
>
> This patch add 3 times retry to CMD8 because the Marvell mmc controller
> doesn't obey the power ramp up process in the SD specification 6.4.1.
> (Please refer to figure 6.1 and 6.2 in the specification.)
>
> The CMD0 should be send after power ramp up has been finished.
> However, the Marvell mmc contorller must do power ramp up after the
> first CMD0 command has been send.
>
> This patch also affect existing platforms like Nokia N900 and other
> platforms.
>
> Signed-off-by: Macpaul Lin <macpaul@andestech.com>

Applied, thanks everyone!