Hi Andy,
On Mon, Sep 5, 2011 at 6:45 AM, Andy Fleming afleming@gmail.com wrote:
On Sun, Sep 4, 2011 at 5:18 PM, Marek Vasut marek.vasut@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