Hi Andy, On Mon, Sep 5, 2011 at 6:45 AM, Andy Fleming <aflem...@gmail.com> wrote: > On Sun, Sep 4, 2011 at 5:18 PM, Marek Vasut <marek.va...@gmail.com> wrote: >> On Saturday, September 03, 2011 05:34:17 AM Lei Wen wrote: >>> 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. > > > This seems like the wrong way to handle this. What if another > controller shows up, but it takes *4* retries. Or *5*? > > Or *100*? This sort of knowledge should somehow be embedded in either > the driver for that controller, or the board > code. Not the generic MMC code. > > Maybe put it in the init code for the controller? >
The card after the cmd0 need sometimes to be stabilize. Linux also add some kind of mmc_delay function inside the mmc_go_idle() fucntion in the generic framework. The retry time cannot be 100 that much. :) Since the 74 clocks is such short time, that even the second try would serve good. Make it a part of generic could remove the ugly handling in the controller driver itself, and others also could benefit from it... Best regards, Lei _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
