On Fri, Sep 16, 2011 at 6:33 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: > Do you know the source of that info? No, not more than what the comments say. It also seems that the first delay was originally 1ms and at some point it was increased to 2ms (commit f9996aee36921e8f1d499de1b2ea380855cf6d97 "mmc: increase power up delay"). Later on both delays were increased to 10ms (commit 79bccc5aefb4e64e651abe04f78c3e6bf8acd6f0 "mmc: increase power up delay"). > It probably also justifies what we need here. 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 ? > If short delays are needed when messing with power in the powerup path > (i.e. "we just touched power state, give power lines a chance to reach > that state"), it seems perfectly reasonable for similar (if not the > exact same) things to apply during power down. Sounds reasonable. Though I wonder why this is not abstracted in the regulator code: it only seems reasonable that a power up/down handler will return after the hardware is ready. > I have asked our hardware guys about tracing, and they weren't sure > exactly what I'm asking (and nor am I). Can you be more specific on > exactly how they should diagnose this issue at the hardware level? I > am not familiar with such tasks. I'm interested how does the hardware reacts to the sdio reset command that is sent at this state. There's no response whatsover ? > They were also not surprised that a delay is needed when playing with > power state in this way. Quickly bouncing rails can lead to > indeterminate hardware behaviour. I'm fine with your change. Feel free to add my Ack. Thanks, Ohad. -- 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
