On Fri, Sep 16, 2011 at 5:47 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > Maybe. I was wondering why nobody cared so far about putting delays at > the power down path then, but I guess no one was really powering down > their controllers ? I know Marvell did, using some out-of-tree code, > but IIUC Marvell utilizes the sd8686's reset gpios (much like we do > with the 12xx) to ensure hardware sanity. IIRC you guys don't toggle > them at all ? Yes, I think the power down/up paths are not really tested that much as they are new. I note that even doing fast power cycles as happen automatically during boot, and also by doing ifup/ifdown in a loop are not quite quick enough to trigger this, so it is a bit of a corner case. I could only trigger it in a modprobe/rmmod cycle which is somehow quicker than the other mechanisms. (thats why I didn't realise before we merged the earlier patches, which at first seemed to be working perfectly) We also don't use the GPIOs, as you mention. We could, perhaps via a regulator, but it would be hard to tell if they made a difference. I found that a 1ms sleep here is far more than is needed, even short udelays appear to solve the problem. So if any code were to execute here at all it would probably cause enough of a delay to avoid this problem, effective or not. > I'm interested how does the hardware reacts to the sdio reset command > that is sent at this state. There's no response whatsover ? Thats right, its all -ETIMEDOUT. Including mmc_wait_for_idle(). Its as if the stuff in mmc_power_up() never happened. > I'm fine with your change. Feel free to add my Ack. Great, thanks for being thorough! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
