[U-Boot] [PATCH] mmc: send CMD0 before CMD1 for some MMC cards

[Jaehoon Chung]

Hi Yangbo,

On 07/28/2016 11:45 AM, Yangbo Lu wrote:
> Hi Ziyuan and Jaehoon,
> 
> 
>> -----Original Message-----
>> From: Ziyuan Xu [mailto:xzy.xu at rock-chips.com]
>> Sent: Wednesday, July 27, 2016 9:37 PM
>> To: Jaehoon Chung; Yangbo Lu; u-boot at lists.denx.de; Tom Rini
>> Cc: Pantelis Antoniou
>> Subject: Re: [U-Boot] [PATCH] mmc: send CMD0 before CMD1 for some MMC
>> cards
>>
>>
>>
>> On 2016年07月27日 19:15, Jaehoon Chung wrote:
>>> On 07/27/2016 04:28 PM, Yangbo Lu wrote:
>>>> Hi Tom,
>>>>
>>>> Could you help to assign this mmc patch reviewing to right person?
>>>> It seems no one had reviewed it for almost half year.
>>>>
>>>> And another my mmc patch also needs to be reviewed.
>>>> I submitted in May. Please help.
>>>> http://patchwork.ozlabs.org/patch/624448/
>>>>
>>>>
>>>> Thank you very much.
>>>>
>>>>
>>>> Best regards,
>>>> Yangbo Lu
>>>>
>>>>> -----Original Message-----
>>>>> From: Yangbo Lu [mailto:yangbo.lu at nxp.com]
>>>>> Sent: Wednesday, March 09, 2016 11:00 AM
>>>>> To: u-boot at lists.denx.de
>>>>> Cc: Pantelis Antoniou; Yangbo Lu
>>>>> Subject: [PATCH] mmc: send CMD0 before CMD1 for some MMC cards
>>>>>
>>>>> When the MMC framework was added in u-boot, the mmc_go_idle was
>>>>> added before mmc_send_op_cond_iter in function mmc_send_op_cond
>>>>> annotating that some cards seemed to need this. Actually, we still
>>>>> need to do this in function mmc_complete_op_cond for those cards.
>>>>> This has been verified on Micron MTFC4GACAECN eMMC chip.
>>> If there is no go_idle(), then what happen?
>>> If you share the information more, i can check the more..
>> Sounds interesting, I also want want to know what happen?
>> It seems like you failed in CMD1? The eMMC device was always in busy
>> device within 1 second?
> 
> [Lu Yangbo-B47093] This was an issue which our customer reported and required us to fix in March.
> They used NXP LS1020A platform and Micron MTFC4GACAECN eMMC, and reported they had to add CMD0 as below.
> Otherwise it couldn’t read OCR.
> 
> static int mmc_complete_op_cond(struct mmc *mmc) {
> 	struct mmc_cmd cmd;
> 	int timeout = 1000;
> 	uint start;
> 	int err;
> 
> #if defined (XXX_CHANGED)	
> 	// our eMMC chip (Micron MTFC4GACAECN) requires that it be put in idle mode before
> 	// negociating the operating voltage levels.
> 	mmc_go_idle(mmc);
> #endif	

Well, it seems to fix workaround. mmc_go_idle() means Device Reset.

mmc_complete_op_cond() function has added for reducing the booting time.
If mmc_go_idle() is added at here, there is no benefit, and it should be back to old concept.

I don't agree this patch..now.

Best Regards,
Jaehoon Chung

> 
> 
> I hadn’t reproduce this to get more details about this issue since I didn’t have one this kind eMMC card that time.
> Thanks.
> 
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>>>> Signed-off-by: Yangbo Lu <yangbo.lu at nxp.com>
>>>>> ---
>>>>>   drivers/mmc/mmc.c | 3 +++
>>>>>   1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
>>>>> ede5d6e..82e3268
>>>>> 100644
>>>>> --- a/drivers/mmc/mmc.c
>>>>> +++ b/drivers/mmc/mmc.c
>>>>> @@ -418,6 +418,9 @@ static int mmc_complete_op_cond(struct mmc *mmc)
>>>>>   	uint start;
>>>>>   	int err;
>>>>>
>>>>> +	/* Some cards seem to need this */
>>>>> +	mmc_go_idle(mmc);
>>>>> +
>>>>>   	mmc->op_cond_pending = 0;
>>>>>   	if (!(mmc->ocr & OCR_BUSY)) {
>>>>>   		start = get_timer(0);
>>>>> --
>>>>> 2.1.0.27.g96db324
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>