Hi Yangbo, On 07/28/2016 11:45 AM, Yangbo Lu wrote: > Hi Ziyuan and Jaehoon, > > >> -----Original Message----- >> From: Ziyuan Xu [mailto:xzy...@rock-chips.com] >> Sent: Wednesday, July 27, 2016 9:37 PM >> To: Jaehoon Chung; Yangbo Lu; u-boot@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...@nxp.com] >>>>> Sent: Wednesday, March 09, 2016 11:00 AM >>>>> To: u-boot@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...@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@lists.denx.de >>>> http://lists.denx.de/mailman/listinfo/u-boot >>>> >>>> >>>> >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot